Hi, On 09/20/2013 04:31 PM, Richard Brown wrote: <snip>
So with that all said, I strongly believe we should redefine the goal of this document as follows
"The goal of this document is to:
Serve as main reference to the existing documentation around the process. Provide the big picture of the process to the existing community and those new to it Help us to detect areas for improvements."
+1
"those new to it" includes those SUSE employees who will be joining us in the coming weeks, but doesn't single them out for any special treatment or favour.
Onto the next session I feel is inaccurate/incomplete. I want to talk about the section that starts
Roadmap and Feature Planning. The Release Manager creates the initial roadmap [1] [2] [3] .....
This isn't wholly inaccurate obviously - Coolo does set the timetables and our contributors do define what features and functions will end up in the next release. But there is no mention at all of the opensuse-factory mailinglist, home of the debates between our developers who suggest new features, and the place where the discussions inform and decidee whether or not those features are included in the distribution . Just look at the recent discussions about btrfs and MATE to see how Feature Planning is really carried out in the distribution - a contributor (be they someone from SUSE labs or who-knows-where) comes up with an idea/feature/package set they want to add to the distribution, and our entire active contributor base gets an opportunity to discuss, evaluate, improve, and ultimately decide and execute that decision. The Release Manager of course has final say, but the reality is a lot more nuanced than the picture painted in the current documentation. The implication that 'individual teams decide amung themselves' is false. We're a community that collaboratively develops this distribution through an organic distributed discussion and decision process, our documentation should reflect that.
In this sense I would suggest that we clarify the use of the word "feature" as having potentially multiple meanings. A feature may be a set of functionality, such as a whole DE (MATE, GNOME, KDE) or something that is specific to a given part of the distributions such as btrfs as part of the kernel. Additionally I would say that the document provides the impression that these features are pre-determined before development on Factory starts. Which would also be inaccurate as features get added continuously and organically without a pre-determid plan, for the most part.
I also question the accuracy of suggesting openFATE plays a major role in the Feature Planning process. openFATE does a good job of collecting the desires of much of our userbase, but it is my experience that in most cases the new features we introduce into the distribution are a function of 'what is possible by building on newly available tech from upstream' rather than 'lets create something brand spanking new in order to clear the openFATE request'. Whether or not this is a good thing or a bad thing, whether or not this how we should do things, is a debate the community might want to have, but until we do, I wouldn't imply that openFATE has any major part to play in the Roadmap of openSUSE, that's just not my experience.
Agreed, but even using "Roadmap" as such implies a pre-determined set of "features" we are working toward. The only "Roadmap" we really have is the release timeline as set by the release manager. While the dates on that timeline fluctuate the definition ultimately was driven by the community when we decided on the 8 month release cycle. Experience by the release manager, something we do not have collectively, drives the milestone dates.
<snip>
Release Manager I worry that our beloved Release Manager, Coolo, is both a single-point-of-awesome and a single-point-of-failure. This documentation paints them as the sole arbiter of the Release schedule, and the only one doing a huge amount of the release work, image building, signatures, syncing, etc. It's exceptional work, but I worry that if something were to take Coolo away from us, we'd stall as a project. To me it seems natural that 'Factory Maintainers' could be involved in almost all, if not all, of the Release Managers tasks. This probably wouldn't be in a 'lead' capacity, but would at least ensure that more people knew how Coolo does his magic, rather than just seeing it as magic. This is not just to give 'non-SUSE contributors' an opportunity to be involved in this very important work, but to ensure that our projects Bus Factor is greater than 1
Well in theory the documentation of the release process (https://en.opensuse.org/openSUSE:Release_process) which I have not yet dissected, and the formation of the release team should address the issue with Bus_Factor == 1. However, I do think we are not there yet and more work needs to be done, training, possibly more documentation, more people involved, etc. But maybe we are there and I just don't know it. Agree on all your points about QA. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org