On Mon, Mar 13, 2017 at 3:28 PM, Thomas Deutschmann <[email protected]> wrote: > > Looks like we are disagreeing about the role of a project lead. > > The primary goal of any Gentoo project is to group people working > towards the same goal(s) in small, manageable groups. It shouldn't need > a lead in most cases to control the project members. > > A lead is only needed if the team can't get a decision. >
That isn't the only reason a team might need a lead. A lead might also be necessary if the larger distro doesn't trust the members of the team to make their own decisions. Now that I have everybody's attention, let's take a step back before diving back into that. IMO there are broadly two ways to look at the security project. 1. It is a normal project. If security is a normal project then IMO we don't need any GLEPs. It elects its own leads if it wishes, like any other project. The purpose of the lead is what Thomas suggested, which is to facilitate, break ties, and so on. The project could write its own policies, just as any other project can. They wouldn't need special approval, but they'd still be subject to the general discretion all projects/devs have and nobody would really be subject to those policies except voluntarily. In such a model the security project would touch packages just like any other developer/project would. It would nudge maintainers, and if there was no response it could act unilaterally. I believe that is standing policy across the board - if a maintainer doesn't reply anybody can touch packages already. If there were some dispute, security could escalate the situation to QA. In a sense you could almost view security as a subproject of QA. Since QA is a special project it can override maintainers and the escalation process for that is already established. 2. It is a special project. If security is a special project, then we do need a GLEP to outline what its powers are and how it operates because it doesn't just fall under GLEP 39 like everything else. In such a model security might act without involving QA, within whatever general guidelines are set in the GLEP. In this model the lead MAY have the purpose I got at: the lead isn't just about facilitating the wishes of the project members, but it is also about ensuring that the project conforms to the GLEP and respects the wishes of the larger distro. When more powers are given, more is expected in return. The lead must be accountable in some way to the rest of the distro, which is why it would be appropriate to have them confirmed by the council (and I'd probably steal the other boilerplate from the QA GLEP about the Council appointing interim leads and so on). And this is why I think you are talking past each other. Kristian is thinking in terms of security being a special project, and Thomas is thinking in terms of security being a normal project. Both are making completely reasonable suggestions in those contexts. Personally I'm on the fence on this one, which was why I am not entirely convinced we need a GLEP for this. If security can operate well as a normal project then IMO it should do so. Then we don't need any special powers, and we don't need any special treatment of its lead. There doesn't need to be any special sort of accountability. IMO the normal model is simpler, and I don't want to see a world where every little Gentoo project has to have the Council confirming its lead. The two areas that I see as possibly pushing security towards being a special project are: 1. Masking or otherwise directly touching packages without waiting for the maintainer if the timeline passes. 2. Being able to represent Gentoo on special security mailing lists that have tight distribution. (If somebody betrays this trust Gentoo could find itself cut off from all such lists, so Gentoo should use care here.) I'll finally note that there is also a possible compromise. We might make security somewhat special, but decide that its powers aren't that important and so let it self-govern without forced Council interaction. Even so we should probably create some avenue for appeal so that the next time an argument comes up over whether long-term masks vs overlays are the right solution people feel like they had input into the decision. Apologies if I did not correctly interpret anybody else's stance here; there is always peril in trying to guess what somebody else is thinking. Ultimately I think the question is whether security is more like python, or more like QA. -- Rich
