On 09/24/2013 05:14 AM, Alberto Planas wrote:
Hi,
I will integrate these feedback into the wiki before we can remove the Draft status. My work here is to document what is really happening in the development process. So this document is descriptive, not prescriptive.
I want to discuss the changes that I think that we need to make in the documentation:
* Goal of the documentation
[Remove Explain the process to SUSE employees. ]
""" 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. """
That'll work
* openSUSE Dev. and Int. Process High Level Description
[Reference T1.3 for a better explanation of the process. Reference the mailing list. Downgrade openFATE as a documentation tool]
""" - Roadmap and Feature Planning. The Release Manager creates the initial roadmap [1] [2] [3] by putting in the number of milestones, betas and release candidates that need to be released for the distribution. The schedule is adjusted taking into consideration vacations and other constraints described in the Roadmap Process.
To this point I agree that this is the current practice.
In parallel, developers from the community will decide a set of technical goals for the distribution based on the projected release and freeze dates [4] [5], using the mailing list and documenting these features in openFATE [6][7] or in a dedicated wiki page per project (see T1.3 for a further description about how the features are decided). The feature freezes are scheduled as part of this task. """
For the second part of this paragraph I think it will be important to here from teams like the GNOME and KDE teams that determine major "features". Kernel and tool chain developers should also chime in. While I am not intimately familiar with all the things that go on in this area I have a feeling it is a lot less planned and more organic than the proposed paragraph makes it sound. As mentioned previously this second part of the paragraph just makes it sound we work off a predetermined list for "features", i.e. versions of upstream projects. It is my perception that this is not the case. I think packages just evolve throughout the release cycle and when we reach the various feature freeze point we end up with what happens to be in factory. I don't think anyone can tell at the beginning of the cycle whether we'll end up with kernel 3.12, 3.13, or other. It all depends on upstream releases, while for some parts are reasonably regular but still subject to fluctuation, and the time available for packagers to catch up to the upstream releases. For example if we would ship 13.1 with GNOME 3.8 instead of GNOME 3.10 I don't think there would be anyone able to point to any document/e-mail/FATE reference and say "but you promised GNOME 3.10." In the end "things just happen", at least that is my perception of the "process". But others that maintain larger parts of the distribution need to chime in.
* Product Manager
Looks like that there is some agreement that this role is a SUSE role, and that the name is not precise enough. I propose to change this name and the description in the documentation. I can propose something like "Project Coordinator", "Project Representative", I don't know.
If there is not consensus, I propose that at least we include a note in the role description that the Product Manager is not an openSUSE role, but a SUSE one
Apparently the role exists, although all of those that responded were surprised to hear about it. While there are some questions that would need to be answered, those questions probably address a future state and we do want to focus on the document as a "this is the present state" document. From my perspective, and I would hazard the guess that I am not alone, the Product Manager has no influence, or no visible influence on the distribution or development process. If there is behind the scene influence it certainly needs to get out in the open and for completeness be in the document. The current write up only provides hints and is not concrete thus, it is hard to tell whether or not there is anything there that needs to be unveiled.
* Roadmap and Feature Planning
[Add more relevance to the mailing list, and less to openFATE]
""" - T1.3 Determine the new features. On the mailing list (as the primary channel for discussing ideas and features) and through other community communication channels the new features expected for this release are discussed and defined. Some of those features can be documented on openFATE [6] (not widely used) or the wiki [3]. The features are decided inside the community (in this moment this is done only by a really small number of contributors) or internally in SUSE when there is a relation between SLE and openSUSE: a developer can create a feature in FATE for SLE and then add openSUSE afterward (this kind of feature is not visible outside) At this moment we do not have a strict policy on using openFATE. Some features are also decided later without planning and documentation. If the feature is implemented after the freeze calendar, and explicit approval from the Factory Maintainer is needed for the integration. """
Hmm the beginning of this paragraph once again strongly implies the "per-determent" development model rather than an organic development model. In addition having just implemented a "feature" that trickled upstream from SLE into openSUSE I am not certain that we need to single SLE out. For example, systemd originally showed up in another distro, does that imply that we got that "feature" from the other distribution and should we therefore sing;e it out as a way for us to accumulate features? Let me take a shot at this and see how that works. """ - T1.3 Features in the distribution and project are developed organically. Package and project maintainers contribute upstream changes to Factory for integration. Entries in openFATE and bugzilla as well as feature discussions on the mailing list are taken into consideration and may be picked up by contributors that are interested in developing and maintaining a certain feature/functionality. Origin/motivation of features/functionality that are contributed to Factory are at times unknown and can often be attributed to the interests of the contributor, may those be professional or personal in nature. The release timeline determined early in the release cycle determines when new features/functionality is accepted. Feature freeze is a stepped approach and depends on the impact of the changes, for example the kernel and tool chain will be frozen earlier in the release cycle than features higher up the stack such as changes in a Perl or Python package. """
* Devel Project Integration
[Add the Package Maintainer in the decision to submit to factory]
""" - T3.4 Submit to Factory. Once the Package or Project Maintainer considers the package(s) in his project good enough he/she creates a submit request for Factory. """
This makes it sound as if the decision to submit to Factory is only dependent on the quality of the package. However, I think there are more factors at play, we have plenty of packages that are good enough that remain in the devel projects. How about """ - T3.4 Submit to Factory. Once a Package Maintainer thinks a package is of sufficient quality and is willing to maintain the package in a released distribution the Package Maintainer creates a Submit Request for Factory. """
[Fix a contradiction in X3.1]
""" - X3.1 The Package or Project Maintainer creates a submit request for Factory """
* Factory Integration
Comment from Robert: It appears that in "Factory Integration" the tasks for feeding back changes from "The Factory Maintainer decides to fix an issue inside Factory" to the devel project are missing.
I think that this is T5.5. If the Factory Maintainer decides that he / she want to fix something he become a Package Developer for this moment (fix the issue, create the SR, and integrate into factory). Am I wrong here?
No, that description would be sufficient. However, on https://en.opensuse.org/openSUSE:Development_Process at this moment (2:57 P.M. EDT, Sept 25, 2013) T5.5 reads "Issue notification". Also a search of the page for the word "become" returns empty, which would indicate that I am not overlooking the entry you mentioned. Maybe I am looking in the wrong document.....
* Public Test
[Add Factory testers. Add a new reference]
""" - V7.1 Test in real machine. The user (or developer) can go to software.o.o [14] to download the release and install it in the real hardware. If he / she detect a bug a new bug report is created in bugzilla [19] or / and a mail is send to the Factory mailing list. Also, many users decide to test Factory directly updating the repositories [50], without installing the released media.
[50] How to install Factory http://en.opensuse.org/openSUSE:Factory_installation """
Hope others will continue to chime in, I know the timing right around the release is not ideal and everyone is busy, but if we have this document we'll collectively need to make certain it reflects out understanding of the "process" 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