contributions

[Reinhard Tartler]

Scott Kitterman <ubuntu at kitterman.com> writes:
>> a) Too cumbersomely
>> b) The round-trip time is too high that make duplicate work more likely
>> c) the use of lp restricts possible contributors
>> d) The complete list of outstanding merges must be easily visible.
>>
>>
>>For a), I image that we can craft scripts a la 'request-sync.py'.
>
> Yes, but the (lp: #nnnnnn) is not scriptable.  It needs the mail back from 
> LP to get the number.  Personally, my merge workflow involves testing with 
> exactly what I intend to upload.  So even with such a script it's send the 
> mail, wait aroung for a reply, copy/paste in the bug number, try to remeber 
> what points exactly I want to look for when I test, and move on.

Technical proposal: Per policy, we allow per source package exactly one
'merge bug'. This is checked by the script. If there are 2 bugs, the
script should report that and abort, or better, offer merging the bugs
if possible. This way the script  could be called 'claim-merge.py'.

> From my perspective, such a script would help, but not eliminate the 
> nuisance.

With my proposal, I think you wouldn't have to deal with bug numbers at
all if there is really only one merge bug.

>>For b), I don't really beleive that is really a problem. If someone
>>notices a duplicate bug, he can surely mark it as such and coordinate
>>the contributors (may them be Ubuntu Developers or not).
>
> The risk is admitedly small, but due to not refreshing web pages and such 
> is non-zero, particulalry given the lag in mail processing.

Right. However, I think the risk is acceptable. And way lower than the
process we have right now. May I point to Debian, where there is a
similar procedure, bug using debbugs, which has a latency of 15minuts at
minimun?

>>For d), I think this can be solved technically by launchpad tags, and a
>>scraper that presents all bugs tagged 'needs-merge' or something
>>somewhere on http://people.ubuntu{,wire}.com
>>
> Potentially, but we already have such a list of packages on MoM/DaD.  Why 
> don't we just use the list we have.  It seems like a lot of work and 
> inconvenience to LPify a list we already have.

Agreed, if we manage to merge MoM/DaD and provide a link to 'the' merge
bug of the package.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4