Launchpad bug statuses

[Emilio Pozuelo Monfort]

Forest Bond wrote:
> Hi,
> 
> On Wed, Oct 03, 2007 at 07:56:59PM +0200, Emilio Pozuelo Monfort wrote:
>> Christian Robottom Reis wrote:
>>> On Wed, Oct 03, 2007 at 02:54:53PM +0200, Emilio Pozuelo Monfort wrote:
>>>>> Who is going to add upstream projects for the thousands of packages in
>>>>> Ubuntu?   I don't imagine this approach is very scalable.  
>>>> I agree with that. It doesn't look valid for thousands of packages, but
>>>> even for one I don't think it's Ok. Not because of the work, but why
>>>> should we have an upstream bug tracker if we aren't upstream?
>>> There is some confusion here. Launchpad allows you to register a project
>>> and to indicate that it uses an external bugtracker. Firefox is one such
>>> example project (bug there are many):
>> I know that, and I have registered some external bug trackers to add bug
>> watches. And that's useful (although as everything in this live, it can
>> be improved). However, that's not what I was talking about. I was
>> replying to this:
>>
>>> Isn't the correct way to handle this to add the upstream project to
>>> launchpad and set the bug so that it also affects upstream?  Then you can be
>>> explicit about the bug's status upstream.
>> And that says (or at least I understand) that I don't need to add a
>> remote bug watch, but register the project in Launchpad, and then open a
>> task for it (without being a remote watch). Then *I* would be able to
>> change the status. That just adds a *lot* of work to the workflow, and
>> thus I disagree with it.
> 
> I think this is a reasonable thing to do if the upstream project doesn't have a
> bug tracker, or if they aren't tracking the bug in question.  Why wouldn't it
> be?

Because a) I don't think you *should* create a bug tracker for upstream
if you are not upstream (note that I'm not referring to bug watches
here, you can create a project, set it as "Doesn't track bugs in LP",
and set up a remote bug tracker), and also because this means increasing
a lot the work you have to do, and I'm not that bored ;)

> One way or another, you have to track the following bits:
> 
> * Has upstream committed a fix for this bug?
As we have said (and I understand you think this isn't the best way to
act, but IMHO it is with the tools we have ATM), you can mark the Ubuntu
task as Fix Committed. And then just add a 'LP: #nnnn' in
debian/changelog when you upload the next release. Really easy, and you
don't have to change the bug status 4 times.
> * Has uptream released a fix for this bug?
Same as above.
> * Has Ubuntu committed this fix?
> * Has Ubuntu released this fix?
I can't see a big difference between fix committed and fix released for
a distribution, at least not for the packages I touch, since when the
fix has been committed, it has been committed to the archive, and the
delay there can be is small, unless there's a freeze.

> 
> If it seems like a lot of book keeping, it's because it *is*.  You are tracking
> a fair amount of data, and expecting LP to enable you to do it with a single
> status field.  That hardly seems fair.

Maybe, but forcing me to create products, and to creating (false)
upstream bugs in those products, and to updating them myself (when I'm
not an upstream developer) doesn't seem like the Good Way ™ to act.

> 
> With a couple of usability enhancements to LP, I don't see this kind of use case
> being all that unwieldy, and I'm not really *that* fond of paperwork.
> 
> -Forest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20071003/41d2599d/attachment-0001.pgp