contributions

[Stephan Hermann]

Moins,


On Sun, 18 May 2008 09:56:16 +0200
Reinhard Tartler <siretart at ubuntu.com> wrote:

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

Why not moving away from this LP thingy for merges?
We could use something like the RT for those "tasks"?
Adding a "send mail to an RT service" for merging/syncing when MoM
runs?
Someone can catch one of those tasks and mark it as "yes, it's mine,
don't touch"...close it after he filed a sync bug, or got it sponsored?


Why RT? It can be used by people without LP accounts and gpg keys
attached. It can be driven through simple eMails...
It's realiable and fast and could be hosted anywhere...



Regards,
\sh