"Scott Kitterman" <[EMAIL PROTECTED]> writes: > This would help with preventing duplicate work, but I do see how that > would address my concern about having to wait to get a bug number?
What would you need the bug number for? The only reason I see is to add a propoer comment in debian/changelog. Therefore I'd suggest the following UI: # grab-merge --close which internally fetches the bugnummer from launchpad and calls 'dch --closes $bugnummer', or bails out with a descriptive error number. This way you won't have to deal with bug numbers at all. > You still need to close the bug once the merge is uploaded. Just let malone close it. > Except in Debian if I'm the Maintainer I have a reasonable expectation > that no one is going to upload a new version of my package without > discussing it with me first. This assumption doesn't hold for Bug Squashing Parties, where 0-day NMUs are accepted. You still need to do the paperwork and file bugs with patches, but the principle idea is very similar. > I'm still not understanding what having the bug buys us? Maybe your claim > merge script could submit to the new MoM and insert a comment that X is > working the merge? Issues I'm trying to solve: - make the merge process more straightforward - lower the risk of duplicate work - make it more visible who is working on what merge Per definition, the assignee of a malone bugtask is the one working on the merge. It would be very useful if DaD was taught about these merge bugs and reproduce that piece of information. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
