Re: Merging SRU and release team, leaving
Hello all, since there's some concern about merging the teams, and I don't have a strong opinion either, let's ditch the idea for now? So I guess what remains of my original mail is the proposal to have a more regular schedule of who does SRUs. I already have my hands full with cleaning up my remaining 13 work items and doing some stable+1 stuff before I move to QA in June, so I'm afraid I won't have too much time for SRUs any more. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
I'm willing to help out with SRU team work. I certainly don't have enough time to offset your departure, but I should be able to do some of it. Scott K -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
On Wed, 2012-05-23 at 11:57 +0200, Martin Pitt wrote: Hello all, since there's some concern about merging the teams, and I don't have a strong opinion either, let's ditch the idea for now? That seems to be the consensus from the list discussion. I'll update the UDS blueprints and artifacts to refer to this thread, and reflect it. So I guess what remains of my original mail is the proposal to have a more regular schedule of who does SRUs. I already have my hands full with cleaning up my remaining 13 work items and doing some stable+1 stuff before I move to QA in June, so I'm afraid I won't have too much time for SRUs any more. Clint, Chris - what are each of you signing up for? Thanks, Kate -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
On Wed, May 23, 2012 at 01:28:03AM -0700, Clint Byrum wrote: Excerpts from Steve Langasek's message of Tue May 22 17:21:58 -0700 2012: On Tue, May 22, 2012 at 06:24:11AM +0200, Martin Pitt wrote: 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 guess I don't agree that putting everyone in one pool results in a more even distribution of workload. It might play out that way, or it might result in a subset of people now doing all the work for *both* sets of tasks. ;) It sounds like we aren't actually planning on levelling this out anyway (Chris and Clint will focus on SRUs). I think that's a good thing, but it does call into question the rationale for merging the teams, IMHO. It certainly does sound like this is just a way to perhaps get more people to chip in to the SRU team's work than a way to even out the load. I have to agree that I'd rather see some more people sign on to the SRU team than merge the teams. I don't really have the bandwidth to do any of the things the release team is expected to do. I'm already pretty bad about hitting the SRU queues more than once a week. 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? No, not at all. I'm saying that the SRU team should be enforcing the stated requirements for the SRU process before we accept packages into -proposed, as a gating requirement to prevent SRUs from getting in that aren't actually going to get tested. If we're consistent about applying the rule, we can expect uploaders to comply, simultaneously reducing the SRU team's workload and increasing our SRU success rate. I've been somewhat consistent about requiring that there be a TEST CASE in the bug description, and usually the full Impact and Regression Potential as well. I definitely let it slide more than I should, and I think we as a team should probably be more forceful about having the required fields in the bug description before accepting. I'd be interested in doing some analysis on past SRUs to see how much more successful bugs w/ a TEST CASE are than those without. I'm happy to do this work but how would you define success? A quicker turn-around time? The package not being removed from -proposed? Actually, how would we find the bugs that never had been verified and the package removed from -proposed? -- Brian Murray signature.asc Description: Digital signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
On Wed, 2012-05-23 at 07:55 -0400, Scott Kitterman wrote: I'm willing to help out with SRU team work. I certainly don't have enough time to offset your departure, but I should be able to do some of it. Thanks Scott. :) -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
On Mon, 2012-05-21 at 17:08 +0100, Iain Lane wrote: Hey, On Mon, May 21, 2012 at 10:24:02AM +0200, Martin Pitt wrote: […] 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. Is it necessary to read this as incoming email rather than just reviewing the bug activity when processing from pending-sru? I guess maybe then you wouldn't catch bad updates in -proposed which nobody tags v-failed? Does this happen a lot? * 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. I wonder if pending-sru could be augmented to aid with processing a bit, by floating packages which are ready to be acted on to the top, like - v-done SRUs 7 days - v-failed SRUs - Uploads waiting in UNAPPROVED So that it's not such a slog to get a bit of SRU processing done and there's less chance of things being dropped. I don't know that every one of us will be able to volunteer enough time to be on regular duty. AFAICT the Archive Days thing has pretty much gone away now, probably because the team was organised well enough that it was unnecessary. I hope the same would happen for SRUs too. Looking at pending-updates now for the first time properly, there are a ton of bugs there that it seems are stalled and have been for quite some time. It's a bit overwhelming, but I guess that most of the entries are just stalled bugs. Can they be hidden by default? It doesn't seem that the SRU team is really going to do anything about them. I agree with Steve; this is a failure of our process. I was talking with Martin at UDS about this, and we thought that a script to detect such uploads and ping the bug for testing, followed by removal from -proposed would be a good start here. Additionally, I said that I should be able to find the time to write such a script at some point. 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. Your new gig sounds extremely interesting, congratulations again! signature.asc Description: This is a digitally signed message part -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
Hiya, On Tue, May 22, 2012 at 12:26:18PM +1000, Christopher James Halse Rogers wrote: Looking at pending-updates now for the first time properly, there are a ton of bugs there that it seems are stalled and have been for quite some time. It's a bit overwhelming, but I guess that most of the entries are just stalled bugs. Can they be hidden by default? It doesn't seem that the SRU team is really going to do anything about them. I agree with Steve; this is a failure of our process. I was talking with Martin at UDS about this, and we thought that a script to detect such uploads and ping the bug for testing, followed by removal from -proposed would be a good start here. Additionally, I said that I should be able to find the time to write such a script at some point. Indeed it clearly is, and of course doing something about it is preferable to inaction. I was just suggesting that, if it was true that we're never going to look at these bugs, then they should just go away. I'm glad to hear that that's not the case. :-) Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ] signature.asc Description: Digital signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
Hey, On Mon, May 21, 2012 at 10:24:02AM +0200, Martin Pitt wrote: […] 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. Is it necessary to read this as incoming email rather than just reviewing the bug activity when processing from pending-sru? I guess maybe then you wouldn't catch bad updates in -proposed which nobody tags v-failed? Does this happen a lot? * 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. I wonder if pending-sru could be augmented to aid with processing a bit, by floating packages which are ready to be acted on to the top, like - v-done SRUs 7 days - v-failed SRUs - Uploads waiting in UNAPPROVED So that it's not such a slog to get a bit of SRU processing done and there's less chance of things being dropped. I don't know that every one of us will be able to volunteer enough time to be on regular duty. AFAICT the Archive Days thing has pretty much gone away now, probably because the team was organised well enough that it was unnecessary. I hope the same would happen for SRUs too. Looking at pending-updates now for the first time properly, there are a ton of bugs there that it seems are stalled and have been for quite some time. It's a bit overwhelming, but I guess that most of the entries are just stalled bugs. Can they be hidden by default? It doesn't seem that the SRU team is really going to do anything about them. 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. Thanks for your work! You'll be missed :( Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ] signature.asc Description: Digital signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
Re: Merging SRU and release team, leaving
On Mon, May 21, 2012 at 05:08:17PM +0100, Iain Lane wrote: Looking at pending-updates now for the first time properly, there are a ton of bugs there that it seems are stalled and have been for quite some time. It's a bit overwhelming, but I guess that most of the entries are just stalled bugs. Can they be hidden by default? It doesn't seem that the SRU team is really going to do anything about them. To the contrary, I think stalled SRUs like this by and large represent an SRU process failure that the SRU team needs to take responsibility for - either by making time to toss stalled SRUs back out of -proposed, or by making sure they're on track to be SRUed before accepting packages into -proposed in the first place. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
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
Re: Merging SRU and release team, leaving
Iain Lane [2012-05-21 17:08 +0100]: 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. Is it necessary to read this as incoming email rather than just reviewing the bug activity when processing from pending-sru? I guess maybe then you wouldn't catch bad updates in -proposed which nobody tags v-failed? Does this happen a lot? It does, yes. You also need to pick up testing feedback where people say that they tested the proposed version and it works, and then marking it v-done. Jean-Baptiste does that a lot (he's apparently reading the bug mail), but not for all the bugs (or maybe I just happen to get to those first). I would be happy with a workflow that scales more efficiently with a larger team and round-robin reviewers. Scanning the bugs from pending-sru.html and applying v-failed/v-done after 7 days certainly would work as well, if you would prefer that. I just find it vastly faster to process new bug mail in mutt than having to open and scan all the bugs in Launchpad, but that's a matter of preference. I wonder if pending-sru could be augmented to aid with processing a bit, by floating packages which are ready to be acted on to the top, like - v-done SRUs 7 days They can certainly be ordered differently, or get a different fg/bg color so that they stand out better. Feel free to hack lp:ubuntu-archive-tools sru-report (and roll it out with bzr pull on lillypilly). - v-failed SRUs These already stand out rather well with the bugs marked red. But again, visual improvements are always possible :) - Uploads waiting in UNAPPROVED These already have the +queue pages. I don't think there's much benefit in replicating them on pending-sru where you can't actually do anything about them. Looking at pending-updates now for the first time properly, there are a ton of bugs there that it seems are stalled and have been for quite some time. It's a bit overwhelming, but I guess that most of the entries are just stalled bugs. Can they be hidden by default? It doesn't seem that the SRU team is really going to do anything about them. I don't think they should be hidden. In the past I went through the bugs of uploads that had been in -proposed for more than three months and sent a ping, and then removed them from -proposed a week or two after if there hadn't been any feedback. This just cries for automation, I just never got around to scriptify this. Thanks for your work! You'll be missed :( Thanks! -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Merging SRU and release team, leaving
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) -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
