SRU policy for universe
stefan.potyra at informatik.uni-erlangen.de
Wed Nov 21 12:52:45 GMT 2007
first off, here are the promised numbers (prepared manually from the mails
sent to the motu list, so this may not be too accurate):
03/07: 4 (new policy was introduced)
12/06: unclear: 12?
11/06: old motu-sru policy in effect, no numbers yet
Unless I miscounted, it's interesting to see, that the change from the strict
SRU policy to the new everyone can upload to -proposed didn't really impact
on the number of SRUs performed. Reasons for this might be that people
weren't aware of the new policy (I remember having been asked about it after
the change a few times) or that mails weren't sent to the motu mailing list,
or that the goals of the new policy weren't met.
Mario Limonciello wrote:
> I was briefly discussing this with Emmet and we were both in agreement that
> some sort of peer review system should be re instantiated.
> Another idea I was proposing was maybe requiring it to be sent to an
> ~ubuntu-dev or ~motu PPA.
> Typically you aren't looking for
> linda/lintian/packaging changes on an SRU but instead you want
For peer reviewing, it imho makes much more sense to look at the diff. That
way, it's easy to see if the update is in fact invasive and might break other
things. The actual testing should imho be performed 1) by the uploader and 2)
then in the proposed pocket.
Luca Falavigna wrote:
> Some days ago, the idea of charging ~motu-swat of this role was raised.
I'd rather prefer to create a separate team (as I wouldn't want to force
members of motu-swat to care for sru's), of course allowing members of
motu-swat in there.
> Even if a team could claim responsibility to sort Universe SRU
> proposals, this could lead to a bottleneck.
That depends. If (like in the past) we have a motu-sru team with five members
and require 3 acks, this can in fact easily lead to a bottleneck. However
either if the number of members are increased or the numbers of acks are
reduced, creating a bottleneck becomes more unlikely.
> OTOH, leave these bug
> without a easy way to track them could lead to similar results.
Right, and that's one point that I've really been missing from the new policy:
Since there wasn't a dedicated entity to take care about sru's, it appeared
to me that outstanding work didn't get the needed attention (e.g. in the form
of SRUs getting stale in -proposed).
Emmet Hikory wrote:
> I'd be much more in
> favor of something that requried N members of ~ubuntu-dev to ACK, so
> as not block if specific individuals were unavailable for some period
> of time.
As above, I'd prefer a dedicated team so that we have people who are
ultimately responsible to take care. Otherwise I believe that we'll loose
tracking for stuff that needs work, because noone feels responsible to do the
In the fear of a bottleneck, motu-council could evaluate the work of the team
and interfere (e.g. adding new members or removing inactive members) if
things go wrong.
My current idea to get the universe SRU policy in shape is to basically switch
back to the old policy, and reuse the motu-sru team for this (with new
members). To be aligned with main semantics of proposed from main, checking
of proposals should happen before packages get uploaded to proposed. In order
to avoid bottlenecks, we could reduce the number of needed acks to one. Where
someone from the motu-sru team is unsure, he/she could of course state the
doubts and ask for input from other members.
What do you think?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20071121/84416dcf/attachment.pgp
More information about the ubuntu-devel