On Thu, Mar 11, 2010 at 12:03:05PM -0600, Matt Domsch wrote: > * https://fedoraproject.org/wiki/Stable_release_updates_vision I have a problem with this vision statement in that I think the Board is pushing over the line of responsibilities that it has assigned to FESCo and dabbling in implementation details instead of sticking with vision. In particular, FESCo's purview should deal with the concrete usage of rawhide, prerelease, and stable repositories. Here's some changes to the wording that I think tread the line of Board and FESCo better while keeping most of the flavour of the original. * Keeping productivity of users of a released Fedora should be a major goal of our package maintainers Be explicit about this. It's mentioned in the rationale but not in the vision. Yet it's the essential portion of the vision itself. * The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality stream of updates. Good no changes here * Stable releases should provide a consistent user experience throughout the lifecycle Omitted ", and only fix bugs and security issues." some things require adding features, for instance if a DVCS releases a new version with a new repository format that is adopted by hosting providers. Users' productivity is impacted by not being able to use them. The need for a particular feature or how to classify particular types of features are technical questions of implementing a consistent and stable user experience and therefore should be left to fesco and the package maintainers. * Changes to the user experience can negatively affect the user's productivity and therefore they should not be forced upon users of stable releases. Rewritten from "Stable releases should not be used for tracking upstream version closely when this is likely to change the user experience beyond fixing bugs and security issues." The previous wording is couched in terms of releases, bugs vs features, and technical details of how we implement Fedora. The new wording emphasises the overall goal and vision of enhancing the user's productivity. * Close tracking of some upstream branches or releases can bring in changes to the user experience which are not desirable for user productivity. Close tracking of upstream should be done during our development phase when possible and we should strive to move our patches upstream. Combined the upstream tracking portions of both previous bullets. The second bullet felt out of place since it wasn't talking about our update vision but about development. Combining the two makes it more clear that we're contrasting tracking of upstream in released Fedora vs development Fedora. Also made it a subpoint of the previous bullet as it's really an example of it rather than its own vision. * It is desirable for the development branches of Fedora to be consumable by skilled and/or intrepid users so they can participate in testing and see how the upcoming versions will suit their needs. This one's a bit dicey as I'm not certain what the previous wording was meant to convey precisely. Here's the previous wording "More skilled and/or intrepid users are encouraged to use Rawhide along with participating in testing of stable branches during the development and pre-release period." The wording uses encourage, which is an action whereas this is a vision or what the ideal should look like. Do you mean "The Board would like to see a future where people market Fedora's Development Releases to end users", for instance. Also, for the most part visions are implemented by the people who are members of a project therefore it's a bit funny to make an item that seems to be speaking to people who are consumers of Fedora rather than members. Hopefully my rewrite captures what was really intended to be said and redirects it at the members who can bring that about. * In recognition that our users expect that the older a release is, the less changes will occur, the various phases of a Fedora release's lifecycle (from earliest development to EOL) should take a graduated approach to what types of updates are expected. Stable releases, pre-releases, rawhide, etc, are all definitely in the realm of implementation and should be left to fesco to decide which is why I dropped them from the wording. The original wording also doesn't root the technical details in a visionary reason. I try to correct that here as well but I'm not sure I have the correct reason. I originally thought the rationale was to allow for different people's desires to consume more updates or less. Please correct me if that really is the reason for this passage. I actually think this one should be handed entrirely over to fesco to make policy on. Even with my rewrite it's heavy on technical, implementation details. There's many ways to satisfy the user expectation of less changes in an older release. Some ways could even make for less changes for user's that want it over the course of the entire release (while giving those who want every bugfix their updates as well). Mandating a graduated update style really is an implementation question rather than a policy question. * Project members should be able to transparently monitor a new update's process to objectively measure its effectiveness and determine whether the updates process is achieving the aforementioned vision statements. Just corrected grammar and redundancy in this one. -Toshio
Attachment:
pgpkD6lx36wf5.pgp
Description: PGP signature
_______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
