Merging SRU and release team, leaving

[Scott Kitterman]

On Monday, May 21, 2012 12:35:22 PM Steve Langasek wrote:
> On Mon, May 21, 2012 at 10:24:02AM +0200, Martin Pitt wrote:
> > as discussed at UDS [1] we were planning to merge ~ubuntu-release and
> > ~ubuntu-sru, as the required skills, tools, and processes overlap to a
> > large degree.
> 
> Sorry, apparently I missed the part of the UDS session where this was
> discussed.  I had given Kate my thoughts on this subject prior to UDS, and
> if I had been in this part of the session I certainly would have spoken up.
> 
> My concerns on this plan are, unsurprisingly, similar to my concerns for the
> proposal to make ubuntu-release part of ubuntu-archive:
> 
>  - The tools are all similar, yes, but there are distinct processes for each
> area of responsibility, which require a certain amount of training.  If
> we're batch-combining the teams, how are we making sure that the necessary
> cross-training is taking place?
> 
>  - Dilution of responsibility: if everyone is responsible, no one is
>    responsible.  The finer-grained teams are a useful division of labor,
>    helping to ensure that someone is responsible for day-to-day tasks.  Who
>    is making sure we keep up on these tasks in the new scheme?
> 
> To be clear, I have no problem with any individual member of either team
> joining the other team.  I just think that should be done on an individual
> basis and be accompanied by appropriate process training and an appropriate
> level of individual committment.
> 
> I also don't see what problem we're trying to solve by merging the teams.  I
> have certainly never gotten the impression that we're understaffed on the
> ubuntu-sru team - the parts of the SRU process that actually fall to the
> SRU team seem to be adequately covered, and where things fall apart is for
> SRU verification.  I don't think we need more SRU team members to
> accomplish that, I think we need better enforcement of the SRU requirements
> (i.e., make uploaders provide test cases before we accept packages).
> 
> 
> BTW, the etherpad for this UDS session
> (http://summit.ubuntu.com/uds-q/meeting/20699/other-q-release-team-meeting/)
> also says:
> 
>       - adding ubuntu-release to ubuntu-sru, and remove the other members
> 
> Do we really intend to remove Clint and Chris from the SRU team?  Why?  As I
> understand it, they're the two most active members of the SRU team right
> now...
> 
> > Before we flip the switch and add ~ubuntu-release to ~ubuntu-sru, I'd
> > 
> > like to discuss two things for a bit:
> >  * Bug mail: u-sru gets tons of bug mail. A lot of it is irrelevant
> >  
> >    for the SRU team itself, but it still needs to be scanned for
> >    regression reports and testing feedback (when you should update the
> >    verification-needed tag to -done).
> >    
> >    When we merge the teams, the whole release team will get that mail,
> >    which is unnecessary. It would be enough if one or two people get
> >    it and are responsible for watching the mail traffic, it's not
> >    necessary for reviewing uploads or moving packages to -updates as
> >    long as you check the tail of the bug report before doing so.
> 
> I wonder if that's actually a good workflow.  I think it makes more sense to
> have this be queue-driven instead - whoever's on point for the SRU team can
> sweep through the list of SRUs that have met their aging requirements,
> checking bugs for updates and setting tags as needed.  I don't think that
> we need to actually monitor email for this.
> 
> >    This could also be a rotational role ('SRU bug mail guard').
> 
> I will not be volunteering for such a role - I found the SRU team bug mail
> problematic and have already filtered it all to the bit bucket, where I
> intend for it to stay. ;)
> 
> >  * Rotation: With the entire release team now (potentially) doing
> >  
> >    reviews of the stable upload queues, it might be prudent to have a
> >    kind of roster (similar to the "archive admin of the day") rather
> >    than hoping that "someone else will do it". If there are five
> >    people available, we could empty the queues and do the -proposed →
> >    -updates promotion every day, and it should not take more than 15
> >    minutes every day.
> 
> Yep, this echoes my concern above.  I think this is very important to sort
> out *before* flipping any switches, otherwise the flip-switching is
> pointless (and even counter-productive).
> 
> > Finally, with me moving into a new role from June on [2] and being in
> > stable+1 team this month, I'd like to step down from both the release
> > and SRU teams. I'll still be available for mentoring, questions, and
> > the odd "can you urgently review this" actions, but not doing
> > milestone releases or regular SRU work any more.
> 
> Congratulations on the new role, Martin - we'll definitely miss your
> efficient queue-processing... :)

Yes.  Definitely.

I wasn't hadn't seen anything about this before and I share Steve's concerns.

I think it would be better to fix 
https://bugs.launchpad.net/launchpad/+bug/648611 so that +queue access in 
Launchpad matches what the different teams require that to combine them.  I've 
no problem with adding people to all three teams (I'm currently a member of 
two of the three myself (and was in motu-sru many years ago when there was 
such a thing)).

Based on that experience (and also accepting packages for ubuntu-sru members 
that lacked access to do so themselves) I agree that the knowledge/training 
associated with the three different roles is very different.

Additionally, I think the experience level needed to make a qualified member of 
all three teams (or the combined team) is different than for each of the 
individual teams.  A combined team would, by nature, have more stringent 
experience/training requirements than any of the individual teams.  This is 
going to make it harder to grow new talent.

Scott K