Hi, infra. Since my question on IRC didn't get any response, I'd like to open an official request to join infra :). I don't mind not getting full access to everything. I'd like to focus on janitorial stuff, i.e. serving requests issues by developers. For example: - mail aliases, - mailing lists, - possibly ability to suspend rsync when doing big commits, - temporary commit right suspension ability (I'm qa@ as well). While lately I don't have much time for big projects in Gentoo, I am often around at random times and can help getting some minor requests processed fast.
- For general things I think it's fine, (aliases and the like). - We need ways to restrict access to just janitorial stuff though. - What do you mean about 'suspend rsync'? - Does gentoo have an official process for suspending devs? If not we need it before we can allow it, council I think.
(In reply to Matthew Thode ( prometheanfire ) from comment #1) > - For general things I think it's fine, (aliases and the like). > - We need ways to restrict access to just janitorial stuff though. Well, I don't mind having extra possibilities. Just don't expect I'd do too much about them right now ;). > - What do you mean about 'suspend rsync'? I think some of the documentation mentioned that rsync updates can be stopped during mass commits to avoid rsync getting updated mid-commit. Not sure if that's actually done at all, though. > - Does gentoo have an official process for suspending devs? If not we need > it before we can allow it, council I think. Yes, I'll try to add this to Council agenda too.
So, a few weeks ago in the council channel you ranted about the team as well as specifically "the current webadmin" (aka me); and now, completely opposed to your open hostility you're here to "join infra :)". What changed? Given what you would like to work on, I feel like these are not our core needs right now, and we get to this 'janitorial stuff' just fine. Service maintenance and CM migration on the other hand would need hands. On commit rights suspension, you being qa@ is a concern as it violates the separation of powers.
I agree yes in theory, but with a few comments. - mail aliases: I noted the developments of bug 529300 comment c11; The other bit is that there should always be a bug requesting it beforehand. Ideally, they will be created by puppet, then stored into Git by slurping. The puppet portion should also be able to set ACLs to allow for example team leads to edit restricted lists. - mailing lists: see discussions in IRC about converting them for Puppet. They did not map well to cfengine, so are still mostly manual. They need to be puppet resource types. - suspend rsync: this is going to become moot when Git migration is completed; and we try not to use it as is. It's really just temporarily disabling one cronjob. - suspend dev commit: If you DO join infra, you will NOT suspend any dev's commit ability without a VERY strong audit trail and cause. Saying you're QA, and it broke something is NOT strong enough. QA can be the judge of mistakes made, but it CANNOT also enact the punishment. The only allowable case of infra unilaterally taking away a dev's access is immediate security concerns and deliberate malfeasance (rm -rf in a eclass phase outside of sandbox for eg). So even that you'll have the power to do it, you will NOT exercise it while you're also wearing the QA hat.
(In reply to Robin Johnson from comment #4) > I agree yes in theory, but with a few comments. > > - suspend dev commit: If you DO join infra, you will NOT suspend any dev's > commit ability without a VERY strong audit trail and cause. Saying you're > QA, and it broke something is NOT strong enough. QA can be the judge of > mistakes made, but it CANNOT also enact the punishment. The only allowable > case of infra unilaterally taking away a dev's access is immediate security > concerns and deliberate malfeasance (rm -rf in a eclass phase outside of > sandbox for eg). So even that you'll have the power to do it, you will NOT > exercise it while you're also wearing the QA hat. I'd also like to remember you and anyone else that isn't aware, that the policy for suspending privileges by QA is set on GLEP48[1]. While I was in the Council, after much discussion between Council, QA and ComRel[2] [3], the consensus was that the QA lead / deputy or at least 2 members of QA could ask for commit privilege suspension. I admit I didn't follow the changes set by the previous Council when it replaced the QA team, so I don't know if the suspension rules were changed or not. [1] - https://wiki.gentoo.org/wiki/GLEP:48 [2] - https://projects.gentoo.org/council/meeting-logs/20110608-summary.txt [3] - https://projects.gentoo.org/council/meeting-logs/20110308-summary.txt
(In reply to Jorge Manuel B. S. Vicetto from comment #5) > I'd also like to remember you and anyone else that isn't aware, that the > policy for suspending privileges by QA is set on GLEP48[1]. > While I was in the Council, after much discussion between Council, QA and > ComRel[2] [3], the consensus was that the QA lead / deputy or at least 2 > members of QA could ask for commit privilege suspension. I admit I didn't > follow the changes set by the previous Council when it replaced the QA team, > so I don't know if the suspension rules were changed or not. A clarification in that regard would be good. In any case, with your followup, if mgorny is going to do any dev-suspends, it won't be as QA lead or one of those two QA members asking for it. It's being QA _xor_ Infra for handling that. There will be as few grounds as possible for any claims of judicial malpractice. mgorny hasn't responded to my comments, so I'll give him another week before closing as RESO:NEEDINFO.
(In reply to Robin Johnson from comment #4) > I agree yes in theory, but with a few comments. > > - mail aliases: I noted the developments of bug 529300 comment c11; The > other bit is that there should always be a bug requesting it beforehand. > Ideally, they will be created by puppet, then stored into Git by slurping. > The puppet portion should also be able to set ACLs to allow for example team > leads to edit restricted lists. Ok. > - mailing lists: see discussions in IRC about converting them for Puppet. > They did not map well to cfengine, so are still mostly manual. They need to > be puppet resource types. Ok. > - suspend rsync: this is going to become moot when Git migration is > completed; and we try not to use it as is. It's really just temporarily > disabling one cronjob. Ok. > - suspend dev commit: If you DO join infra, you will NOT suspend any dev's > commit ability without a VERY strong audit trail and cause. Saying you're > QA, and it broke something is NOT strong enough. QA can be the judge of > mistakes made, but it CANNOT also enact the punishment. The only allowable > case of infra unilaterally taking away a dev's access is immediate security > concerns and deliberate malfeasance (rm -rf in a eclass phase outside of > sandbox for eg). So even that you'll have the power to do it, you will NOT > exercise it while you're also wearing the QA hat. Understood. I don't know if you expect anything more specific from me here.
mgorny: Welcome Aboard. If you're available this coming weekend, I'll set you up with access, and go over some of the details and intricacies. infra team: Yes, I have listened to the worries raised about mgorny; I do believe in review, that he can be a valuable asset to the team. I hope that the weight of responsibility will garner only professional conduct from mgorny and thus alleviate your concerns.
