Leaving the SRU team due to OEM rotation
John Dong
jdong at ubuntu.com
Mon Apr 19 21:00:36 BST 2010
Sorry, this email got lost in my draft folder.
On Apr 16, 2010, at 6:48 AM, Martin Pitt wrote:
> Hello fellow SRU team members,
>
> I will rotate from platform to OEM in the next six months, starting in
> about three weeks. During that time I won't have time to do SRU
> processing, I'm afraid, so I would like to leave the team during that
> time. The rotation will happen in about four weeks, which should give
> us enough time to do the transition.
>
> The main SRU task is to stay on top of the incoming mails and
> discuss/approve/reject SRU proposals/patches. This doesn't require any
> technical privileges in Launchpad/Soyuz, and John Dong has recently
> stepped up to do a lot of these reviews/proposals, thanks! This is
> certainly the most time consuming element.
>
Thanks for the early heads-up, Martin. Hopefully we'll be able to plan a
smooth transition by that time!
I've been trying to prioritize SRU reviewing work with my free time but
unfortunately I don't seem to have as much as I'd like during the school
term.
> The more technical tasks which I have been doing so far wrt SRU were:
>
> * Regularly check the unapproved queues ([1] and similar for dapper
> to jaunty) to review and accept uploads with queue-diff and
> sru-accept.py [2].
>
> Once an SRU bug is approved, this is mainly about making sure that
> the queue-diff debdiff looks sane and matches the approved one in
> the bug, and then just pressing the buttons (sru-accept.py and
> accepting on [1]). Perhaps this can get some support from the
> archive admins, since without me there are only two people in the
> SRU team left who are also archive admins?
I'd feel more comfortable if the archive admins can do the necessary
button-pushing. This used to be less of a problem when the SRU team and
the archive admins overlapped more, but right now that is no longer the
case.
>
> The debdiff checks/bug discussion is a fairly time consuming task,
> I spend about one to two hours per week on that. The button
> pressing part is trivial time-wise.
>
> * Mark bugs as verification-done/verification-failed/
> regression-proposed once test results come in. This just happens in
> parallel with catching up on bug mail, but needs to be done by
> someone/everyone else in the team.
>
> Since I read all the SRU bug mail anyway, this doesn't take much
> extra time. Open the bugs in the browser while you read through
> them, change the tag, done.
>
> * Regularly check [3] for packages which are ready to go to -updates
> (verified and >= 7 days old). This is again a mechanical task
> without extra policy decisions, and just involves running
>
> $ sru-release karmic pkg1 pkg2 [...]
>
> on cocoplum. This again needs archive admin powers.
>
> This doesn't take a lot of time, something like 10 minutes per
> week.
>
> These three tasks would need to be taken up by someone else soon;
> ideally an archive admin, but if you aren't, we can certainly arrange
> something with the archive admin team for the actual button pressing.
>
> Do you think we need to recruit a new SRU member for this, or are the
> 5 existing members enough?
>
> I propose that we do the handover for the primary SRU responsibility
> soon, and I'll stay in the team for another month to see that
> everything is going well/help out/advise/etc.
Thank you, Martin, for all the effort you've put into the SRU team. I
hope the handoff will be smooth. In general I try to stay on top of SRU
bugs and clear my queue at least once a week, but the task does seem to
take more and more time. Recruiting another SRU member would be nice, as
well as polling existing members on whether or not they are interested
in continuing their role on the SRU team. I think 5 active members is
sufficient to handle SRU matters, though.
On a related note, Martin, what are you thoughts on changing the tagging
scheme a bit for SRU's? I'd like a "needs the attention of SRU team now"
tag (e.g. for when a debdiff is awaiting review). I'd say 80% of my SRU
bugmail tends to be unrelated chatter on the bug report and I'd hate to
be overlooking real bug reports while thumbing through those. If there
were a one-screen view of all the SRU's that are actually awaiting our
review, that'd be great.
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-archive/attachments/20100419/0f93dd2c/attachment.pgp
More information about the ubuntu-archive
mailing list