Role of the Sponsorship Queue

[Stephan Hermann]

Moins,


On Wed, 03 Mar 2010 15:30:05 +0100
Daniel Holbach <daniel.holbach at ubuntu.com> wrote:
> On 03.03.2010 14:37, Martin Pitt wrote:
> > Daniel Holbach [2010-03-03 14:11 +0100]:
> >> In the end only uploaders can upload stuff
> > I'm a bit undecided on that, TBH. On the one hand, simplicity is
> > nice (just having one queue), OTOH we'll never be able to drive
> > that queue down to zero, so it's also a motivation/get things stuck
> > problem.
> 
> I'm not sure I understand. Can you explain what do you mean by
> "motivation/get things stuck problem"?
> 
> Let me recap: we have lots of bugs with patches attached that are
> supposed to fix problems, we don't have enough people to review all of
> them, we probably will never get down to zero. How exactly will it
> help if we'd ask patch contributors to go to queue A if they're
> interested in contributing more closely to Ubuntu Development and if
> not, go to queue B?

If I can have my 2cent on this:

Regarding the sponsors queue (universe that is), we have four types of
patches pending there:

1. debdiffs for bugfixes (source fixes or debian/ packging fixes)
2. debdiffs for merges
3. single patches for bugfixes (which needs to be incorporated into the
package by sponsor X)
4. single patches for "missing functionality / feature" which needs to
be incorporated (when sane) into the package by sponsor X and needs to
be pushed upstream (debian or real upstream)

Topic 1 are the simple ones, check if debdiff applies
on latest package in our archives, testbuild, test run
(eventually) -> upload

Topic 2, I intent to say, that those shouldn't be in the sponsors
queue tagged as "patch", or reporters need to documented those as well
on MoM (which is sometimes not the case) (eventually a good thing is to
add a tag "merge" with the report, so we can do some lpapi magic to
find them)

Topic 3: These are mostly time consuming patches, because you need to
deal with different patch systems before you can include this
patch...then the normal workflow starts, src pkg building, test
building via pbuilder/sbuild, test run eventually. 
For those type of patches I would say, they should be returned to
sender, or we inform the reporter to send it to debian/real upstream,
depending on the time a sponsor has per day/week/month to do sponsoring.

Topic 4: Those patches are delicate...Explanation of Topic 3 apply
here, too, and I remember at least the one (nm-openvpn package) I
incorporated and uploaded, but I really banged my head already for that
on my desk. I should have returned it to the reporter and patch sender,
to also do the kde part of that "missing feature", forgot to tell him
to send it upstream or to debian (depending on the case)
anyways, those type of patches are mostly difficult to judge...do we
take them, do we lose them, or should we inform the sender that the
patch works but is not release ready because some parts (e.g. UI parts
are missing in KDE or GNOME) are just missing, and we would like to see
those parts first fixed, before we take those patches. All in All,
those reports are really time consuming. And I really don't want to see
them in the normal sponsors queue.

A standard bug report (new/wishlist) is sufficient here, a "patch" tag
can be added, but sponsors shouldn't be subscribed.

Regards,
\sh






-- 
| Stephan '\sh' Hermann    | OSS Dev / SysAdmin         |
| JID: sh at linux-server.org | http://www.sourcecode.de/  | 
| GPG ID: 0xC098EFA8	   | http://leonov.tv/          |
| FP: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 |