Colin Watson <[email protected]> wrote:
>On Thu, Jun 14, 2012 at 10:09:30AM -0400, Scott Kitterman wrote: >> On Thursday, June 14, 2012 12:37:46 PM Iain Lane wrote: >> > On this point, I can't be entirely sure (it was some time ago), but >I >> > suppose I was thinking that it would be good to ensure that SRU >team >> > members can use sru-release themselves, which requires upload >privileges >> > due to the use of copyPackage via the API if I'm not mistaken (only >> > -updates would be needed here, not -proposed. -proposed is >probably not >> > so useful, except if we want to ensure that they can sponsor all >SRUs >> > too). >> > >> > If there's also another UNAPPROVED step there then just being able >to >> > upload doesn't gain much: queue admin would also be required. >> >> Not that I get a vote, but I'm glad to see this landing. >> >> I do think the ~ubuntu-sru ought to be able to accept to -proposed >and copy to >> -updates for current/supported releases. This would remove the need >to make >> ~ubuntu-sru members part of ~ubuntu-archive solely for the purpose of > >> performing SRU processing. I'm 100% agnostic on implementation. >> >> Similarly (and I swear we've discussed this before and it's an an LP >bug, but >> I can't find it) I think ~ubuntu-release ought to be able to accept >to -release >> and -proposed, but only for the development release. Similarly, that >would >> remove the need for ~ubuntu-release members to be added to >~ubuntu-archive to >> process the queue during freezes. My agnosticism about >implementation applies >> to this as well. > >This is now done. ... Great news. It seems to me that the next step should be to review the ubuntu-archive membership and remove people that are only in the team due to this permissions issue. Scott K -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
