On Wed, 18 Aug 2010 10:32:41 -0400 Stephen Gallagher <sgallagh@xxxxxxxxxxxxxxxxx> wrote: > Yesterday, there was a long discussion held in #fedora-advisory-board. > The topic of discussion was "What is Fedora?" (Or perhaps "What should > Fedora be?") > > I would like to make a proposal to the Board regarding this topic. > > First of all, I will succinctly say that I feel that Fedora should > be: A stable platform for rapidly developing the next generation of > free, open-source software. > > I know that there are several different camps on this topic. On one > end of the spectrum, we have the people who want Fedora to have a > longer support lifetime, to be stable out the door and be stabilized > for long-time use with no changes but bugfixes made to a released > version. At the other end, we have the people who feel that Fedora > should be a Mecca for rapid development and deployment; that Fedora > should get the newest features fastest, and people who are looking > for a stable environment should look elsewhere. > > I don't believe that these two goals necessarily need to be at odds. > My proposal is this: We should stabilize released Fedoras, while > making it easy to release exciting new features as quickly as > possible. > > To that end, I would propose the following changes to the Fedora > approach. > > 1) We need to define and enforce a set of rules as to what changes are > permissible in a released Fedora. This is going to be the hardest > part, I think. It's easy to say "Major desktop environment releases > are not allowed" and "No ABI changes", but where do we draw the line > on other enhancements? This is a question that will have to be > answered by the Board and FESCo. This already has been put forth by the Board in: https://fedoraproject.org/wiki/Stable_release_updates_vision FESo has been working on implementing this. See: https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas and https://fedorahosted.org/fesco/ticket/382 > I also propose that the method of enforcement should be similar to > that of the current critpath system: Any bug marked "Enhancement" > must be given karma by a proventester in order to make it into a > released Fedora. Proventesters would be expected to understand the > guidelines set down as above. Failure to follow those guidelines > (green-lighting a new major XFCE release, for example) would have to > result in a loss of proventester status (with opportunity to reapply > in the future). So, you would like to expand the critical path to enhancement updates? What if an update has some bugfixes, and some enhancements? You can only mark one. Should bug fix updates get less scrutiny than enhancement updates? kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
