Merging SRU and release team, leaving

[Steve Langasek]

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... :)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org