SRU policy for universe

[Stefan Potyra]

Hi,

first off, here are the promised numbers (prepared manually from the mails 
sent to the motu list, so this may not be too accurate):

11/07: 5
10/07: 8
09/07: 0
08/07: 2
07/07: 3
06/07: 1
05/07: 6
04/07: 1
03/07: 4 (new policy was introduced)
02/07: 2
01/07: 9
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.

Seconded.

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

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

Cheers,
   Stefan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20071121/84416dcf/attachment.pgp