contributions

[Scott Kitterman]

> 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'.

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?

>> 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.

You still need to close the bug once the merge is uploaded.  It could be
done manually later, but that's not ideal from a work flow perspective
either.

>>>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?

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.  I don't think the same work collision
concern exists (I imagine teams work this out for maintained packages in
some team specific way).

>>>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.
>
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?

Scott K