Le Mer 3 Mai 2006 18:55, Martin Michlmayr a écrit : > * Pierre Habouzit <[EMAIL PROTECTED]> [2006-05-03 15:49]: > > IMHO, in his case, he should remove the forward, tag the bug > > upstream, and mention in the bug history that this is related to > > the upstream bug "foo". set the forwarded state of a bug does not > > makes sense to me, if you dont adhere to how upstream deals it. > > The problem I have with this approach is that suddenly you or your > program is dictating how a maintainer has to do their job. In my > specific case, it's not a big issue but it is a general problem of > this script. I hope you'll be able to implement incremental changes, > i.e. to only change something when the upstream but tracker changes > (like aba suggested). > > [snip, put later] > > > [...] > > Maybe you can try and see how fragile it really is.
fair enough. I'll look into that way then, it seems quite reasonnable after all. I liked the idea of the script beeing stateless, but maybe I'll have to give up on this. The other idea behind that is that I wanted to give developpers the ability (see in the TODO) to rerun the pull for some of their bugs. So that means that if the script is not stateless, I have to find a way to share its database across the web. But now that I have aj's tag=>bugs live map, I should be able to use that as a reference of the current pull state, and only change debian tags when I change some usertags. That should not be very hard at all. In fact, that's even a pretty good design after all. Thanks for having make me “think again” ! I'll hack that tonight. > > Also, I don't know how you're planning to change bugs in the future > but I'd like to see one control message per package or maybe even per > bug, and it should be CCed to the bug report (or maintainer) so they > know what's going on. I personnally find the per bug mail a bit violent with the BTS, and think a per package or per maintainer mail would be better. the control mails are currently pretty much uninformative about the reasons why upstreams close a bug or not, and (currently) do not realize a "remote bug subscribe", and don't save the time the Maintainer has to spent to look at a fixed-upstream bug to see if: * his next upload has the fix * he is happy with the fix So I'm not sure there is much benefit in making a per bug mail atm, since it puts more load on the BTS that is quite slow these days, with no obvious benefit. But I've not think about that much atm. Don't hesitate to give your ideas about it though. Le Mer 3 Mai 2006 18:56, Martin Michlmayr a écrit : > * Pierre Habouzit <[EMAIL PROTECTED]> [2006-05-03 16:30]: > > after more pondering, what really miss for me, is a BTS > > "closed-upstream" tag, meaning that the bug is closed on the remote > > BTS, but not necessarily "fixed". > > I don't think this distinction is helpful. Also, it's exactly > opposite to what it means in Debian (where "fixed" is "maybe fixed, > but the maintainer has to ack it" and "done" is "fixed for good > (hopefully)"). good point. -- ·O· Pierre Habouzit ··O [EMAIL PROTECTED] OOO http://www.madism.org
pgpUHBrgSY295.pgp
Description: PGP signature
