-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/18/2010 11:48 AM, Jared K. Smith wrote: > 1) What is the problem with the current way of doing things that your > proposal is attempting to fix? The problem is that Fedora N at the end of its lifecycle is often completely unlike Fedora N at the beginning of its lifecycle. Users have no expectation that a particular Fedora release will remain stable in terms of what packages are available at any given point in its lifecycle. I've heard more than one (non-developer) utter the phrase "Fedora is the only Linux distribution I've ever used that doesn't put any effort into ensuring that it works". Fedora right now is a developer's play-pen. As much as the next engineer, I certainly appreciate being able to play with the latest-and-greatest technology, but I don't think waiting a few months for the next release is a terribly big issue. There's always rawhide or build-your-own if you absolutely cannot wait for something. There are certain things that should never happen in a Fedora stable release without express exception by a ruling body: 1) A major or minor release of a desktop environment should never within a Fedora release. (Bugfix point releases are certainly fine) 2) There should never be a SOname bump in a released Fedora. This is also partly for the benefit of the developers, as SOname bumps tend to cause provenpackagers to do mass-rebuilds, which do not always work properly. 3) No key piece of internet browsing functionality should see a major upgrade during a Fedora release. > 2) How does this change affect our target audience? It's difficult to peg our "target audience", and that's a piece that the Fedora Board needs to decide on. Is our target developers, end-users, corporations? Some combination of the above? I will say that for all of the above targets, having a stable release vision is a major benefit. Knowing that the set of package versions present in Fedora at release will be consistent for its entire lifecycle (assuming no exceptional circumstances) will encourage participation from those who might otherwise turn to other distributions that already have similar stable release visions implemented. > 3) How does this change affect our packagers and developers? Are they > more or less likely to contribute to Fedora because of this change? I dislike prognosticating, but I will attempt to enumerate the pros and cons from a developer perspective. Pros: A stable release means that it will always be possible to develop against the existing packages and know that you won't be putting in any late nights trying to rebuild against the latest e.g. Boost libraries because it no longer behaves the way it used to. Cons: It adds a more controlled process to a culture that thrives on independent design. The added requirement for proventester review of enhancement requests (as well as the possibility that The Man will decide that a new enhancement is too disruptive for the stable release) could discourage some developers from playing. I think we can work around the cons somewhat by working to facilitate the existence of public yum repositories through Fedora People and/or Fedora Hosted services. The idea would be that Fedora itself would remain a stable system, but for those developers who really want to push (e.g. XFCE N+1) along, they can provide a yum repository that is compatible with the base Fedora. These repositories would have to be publicized somewhere on Fedora's web presence. > 4) Have their been other attempts over the past couple of years to > solve this same problem? Can you identify where or why they failed? > Answering this question might be impolitic. There have been a few other attempts to do similar in the past. The largest obstacle I've seen to a stable release vision has always been the vocal minority of the groups that are "hurt" by such decisions. I refuse to identify by name or implication any of these groups, but I think at some point we simply need to decide whether it's more important to Fedora as a project and as a distribution and operating system whether it's more important to have a product that works, or a product that's constantly lurching towards the next big thing. >> 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. > > While I certainly agree that you've hit *part* of what Fedora should > be, I think our vision has to be a bit wider than that. Fedora is > more than just a operating system for building the next version of the > Fedora distribution. Fedora is a community first, and the primary > fruit of that community is the distribution. The Board is currently > working on a vision statement for Fedora.(mizmo posted her version to > the list earlier this morning, and I'm working on my own version too > -- we'll be discussing this in our Board meeting on Friday.) Once > that's agreed upon by the Board, we'll then work with FESCo to > evaluate your proposals and give them the attention and discussion > they deserve. Please see the word "succinctly". I was summarizing my views on this particular topic. I agree completely with your assertions about community first. I would like to remind the Board that with communities larger than about three members, it is impossible to please everyone all of the time. Sooner or later, a stand must be taken to decide the future. Not everyone is going to like it, and some will protest loudly and [metaphorically] violently. Some will even have a tantrum and then take their toys and go home. I ask: are those the people Fedora wants? - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxyZDsACgkQeiVVYja6o6MBnwCfROMpYCHxkP/PRM8uAzJMR34K jqgAnimm4bRYiKif0XSwBJXc5bVPKHwy =04Mh -----END PGP SIGNATURE----- _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
