contributions

[Reinhard Tartler]

"Scott Kitterman" <ubuntu at kitterman.com> 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