Re: Launchpad bug statuses

[Emilio Pozuelo Monfort <pochu@xxxxxxxxxx>]

Christian Robottom Reis wrote:
> On Tue, Oct 02, 2007 at 11:32:25PM +0200, Emilio Pozuelo Monfort wrote:
>>> So this is interesting, because ideally you want some record that the
>>> bug has been forwarded and fixed upstream.
>> What I want is the bug to be fixed ;) I don't care that much whether
>> there's a record or not (it may be good to have it, but won't hurt if it
>> isn't there).
> 
> Well..
> 
>>>     - Third, a question: why don't you report the bug upstream anyway,
>>>       and update its status manually? Too much work?
>> This looks like the second question, but yes, why should I report it in
>> SF if I ping the upstream author, he takes a look at the code, and fixes
>> the issue? It looks useless to me.
> 
> The software engineer in me does appreciate it when he finds that
> changes in the code are attached to a bug report which I can look at
> later to try and figure out rationale, timing and responsibility.

I understand you, and see your point. But if forwarding the bug report
to the remote bug tracker, and then adding a bug watch takes e.g. 3
minutes, whereas pinging on IRC takes 10 seconds (and it also means a
fast response) then I prefer those 10 seconds. But this is not always
possible, and not always desirable. However I think if both forwarding
the report and pinging on IRC took the same time, I would forward it.

> But I
> agree that we need to be practical and I'm still not sure what sort of
> UI would help you there. Maybe if the bug UI was just faster to
> use (i.e. full-ajax direct manipulation) this would be less of a
> problem.

You could make this easier, yes. For example, if adding a bug watch
meant opening a portlet or elsewhere, and then introducing the
#bugnumber or the url from the upstream bug. Instead of having to go to
+affectsupstream, and then going back to the bug report.

> 
>>>     - Fourth, would it help is Launchpad made it really easy for you to
>>>       post the bug to SourceForge, perhaps opening the bug-filing page
>>>       with all your details filled in and just waiting for you to
>>>       submit? 
>> I think so. That would be really useful, since that would save a lot of
>> time (not that reporting a bug takes one hour, but when you report a
>> lot, then there's a big difference). This would have a big risk, though,
>> which is that there could be 'spam' in upstream's bug trackers, but this
>> could be avoided by only letting people in the Distribution Bug Contact
>> team to report bugs upstream using that method.
> 
> Well, my initial thoughts would be that you would need to have an
> account in the upstream bugtracker to actually forward the bug.

I don't think this is a big problem, at least for bug triagers. I
personally have an account on most of the big bug trackers (SF, b.g.o,
fd.o...) and in those small trackers for packages that I triage.

If you could implement this, the new workflow for forwarding a bug to
upstream could be:

- Clicking on 'Forward to Upstream'
- Add some information to the description, or change the summary (if
necessary)
- Introduce the remote # bug number or url into Launchpad so it adds a
bug watch (not sure if this could be automatized).

I think I'll surely forward more bugs than I actually do.

> This is
> complicated for trackers such as debbugs, but would address this concern
> for most other bugtrackers. It is somewhat cumbersome, but not too
> cumbersome for Seb's b.g.o use case or sourceforge.net in general, since
> you only need one account for the N projects hosted there.

Attachment: signature.asc
Description: OpenPGP digital signature