Merging SRU and release team, leaving

[Martin Pitt]

Steve Langasek [2012-05-21 12:35 -0700]:
>  - 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?

Particularly for handling packages and the +queue packages, the
skills, processes, and tools are pretty much identical. This is
particularly obvious at the end of a release cycle where freeze
exceptions gradually shift into SRUs, and sometimes it's not even
clear at the time of accepting into -proposed whether it's going to be
an SRU or into the release.

That doesn't apply to other tasks of the release team, such as doing
milestone releases of course. These still need individual training.

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

I agree, we need to figure this out as a prerequistite, if and when we
do the merge. To a smaller degree this is already a problem with the
two existing teams, though (e. g. reviewing FFEs for ~release or doing
SRU reviews for ~sru).

> I also don't see what problem we're trying to solve by merging the teams.

I do not have a strong opinion about it, but it would simplify the
structure a bit and provide a more even distribution of workload
(assuming that we solve the "who is responsible today" problem), as
well as increasing the chance of catching an active member on IRC.

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

~ubuntu-sru does not actually do verification. We expect users and in
some cases ~sru-verification to do that. So far ~sru is reasonably
well staffed, but if I'm leaving the team there might be a gap (I'm
still doing the majority of processing at the moment). Also, Clint and
Chris do not have cocoplum access, so they cannot process kernel SRUs
which bump ABI.

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

It sounds you would like to move the testing responsibility more
towards Ubuntu's/Canonical's QA team?

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

The idea was certainly to add them to ~release instead, but they would
continue to focus on SRUs.

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

If that works better for you, sure. But even though it's a lot of mail
I still find it faster to process mails than to open and look through
the SRU bugs, but that's a matter of preference. I mostly wanted to
point out what I'm currently looking for in these bugs, and how to
filter the mail.

> Congratulations on the new role, Martin - we'll definitely miss your
> efficient queue-processing... :)

Thank you!

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)