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.
signature.asc
Description: OpenPGP digital signature
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
