= phenomenon =
As WGs push towards defining their goals and products, they are going to want to make decisions on various non-technical aspects. For example, the draft Workstation PRD speaks to making it easy to enable third party repositories to bring in software that isn't available in Fedora repos and isn't proprietary. E.g. Google Chrome. To a certain degree this goes against the current policy of not enabling 3rd party repos that Fedora has long held to.
= reason =
While this specific example needs to be addressed, the underlying question here is how much autonomy do the product WGs have. Does FESCo foresee a model where decisions are made in the WG and communicated through the liaison to FESCo, or the liaison brings the proposal to FESCo before a decision is made? Something else entirely?
This is clearly not intended at decisions that are fairly technical and non-controversial. E.g. I don't think we want FESCo to be involved in deciding if background art for Workstation should be different from everything else. Some judgment call on the proposal is going to have to be made, but it would really help to understand how FESCo sees these larger issues playing out.
The WGs are going to want to operate mostly autonomous and FESCo has seemed to lean that way. It's a question of where that line is drawn and how.
This is a pretty tough problem because I think that the products that the Working Groups produce should have a degree of freedom to diverge from each other but that there are certain aspects that still need to remain common to all of them.
I can draw a line around some and say it's because they make use of shared resources that they should not diverge. This applies, for instance, to the release cadence which requires sharing infrastructure, release engineering, and qa resources. If those resources were ever split between the products in the future, these sorts of things might be able to diverge in the future. For these things, fesco probably makes sense as a body that can assemble the desires of the various products and coordinate with the shared resources to figure out what's possible and what's not.
There's others where I don't see something that I could easily say is a shared resource but more of a shared... philosophy. The example you gave of enabling third party repositories (and also, which third party repositories... are we okay with promoting coprs but would not promote jpackage, for instance?) falls in this category for me.
A third category would include other things such as packaging guidelines and the no-kernel-modules policies which are technical in nature and I think need to remain common to all of the products that the working groups create.
Up to here I've only talked about things that should not diverge. But if there were no divergencies, what would be the purpose of having separate Products and Working Groups to guide each of those? As a baseline, I think we start by saying that anyplace where spins were allowed to differ should be allowed to diverge in the Products. On top of that we should explicitly add things from the technical group that we're okay with diverging now. In the past we've had fairly centralized control (or at least pretended to) over what services are allowed to start by default, whether SELinux was allowed to be disabled, whether certain services were mandatory, etc. We should take each of these general areas and ask whether we want them to be common to all things that are called Fedora or if they can diverge in each product.
Perhaps after a dozen or so of these cases we'll perceive a pattern and be able to lay down a general rule about what we want to be common and what should be allowed to diverge between them but I don't think we can know that until we've had some experience identifying which is which.
AGREED: The question is too general. Please bring up specific cases to FESCo's attention as they come up. Specific cases should include anything related to differences from existing Fedora policies, guidelines, or practices. However, autonomy over things already decreed as allowed by Spins to change can be assumed. We expect this will becoming more clear over time. (+8,0,0) (nirik, 18:37:31)
Login to comment on this ticket.