Hi, On 03/04/2010 09:59 PM, Doug Ledford wrote: > Obviously, some people want this and some don't. It isn't appropriate > to simply hand down an edict that things will be one way or the other if > we truly consider Fedora a community run project. It must be a > community decision. That means, as Adam Williamson pointed out, this is > likely a decision to be made by the board, based upon what the community > wants and what's best for Fedora. > > But let's be clear. That's a *policy* decision. One of the things that > got very confusing in the previous thread(s) was the intermixing of > policy decisions and technical issues. For instance, Kevin's response > to my proposal was all about technical issues he saw. Technical issues > are almost always solvable if you have a specific policy you are trying > to implement. So one thing I think people should keep in mind is that > policy decisions should always lead to technical decisions, *not* the > other way around. We should decide what we want ourselves to be and > what our policies are, and then that should guide our infrastructure, > our tools, our work flows, and our processes. We should never allow > things to flow in the reverse direction. We should never allow a > current tooling limitation to set our policy, modulo that our policy > should acknowledge and accommodate for the time necessary for tooling > changes to take place or for the limitations of our resources. > > So, I'm going to reiterate my policy suggestion: > > Make Fedora releases (all of them) stable in nature, not semi-rolling. One size does still not fit all, although this is a great idea for most packages in Fedora for packages in certain niches this is a bad idea. I've said this before (and got 0 response), I believe there should be some divide made between core packages (with core being quite big, not the bare essentials, but also most of all desktop environments, etc.) and non core packages. For example I really see no reason not to upgrade some EDA tool to the latest and greatest if the maintainer thinks that there are good reasons to do this, because the group of EDA users bitten by potential regressions is small and EDA users are highly technical skilled, so know how to downgrade if needed. Another example is multiplayer games. In quite a few online gaming communities, most of the community moves over to the latest release once it is sanctioned stable by upstream. If the client <-> server version need to be in sync (which they often do because they need the exact same maps), then this means that our "stable" version in F-released might become worthless pretty quickly as there are no or very little "stable" version servers available to play on. I strongly urge FESco to come up with a policy which is flexible enough to handle these kind of special cases, without requiring going to rel-eng for an exception each and every time. And to mandate that the tools are flexible enough too. Also I cannot get rid of the collective punishment feeling here, because a few people do crazy things, ALL of us loose the right to apply common sense and have to adhere to strict policy and jump to even more hoops to get updates out there. How about a FAS flag which decides if a maintainer can skip updates-testing, which default to yes, and take this away from people who show to little restraint in skipping updates-testing ? > Make rawhide consumable as a semi-rolling release itself. We already have this it is called early branching of the next release. I would fully agree with you if it were not for the early branching feature, which means we effectively already have such a release, except the first 2 months or so after a release, at which time rawhide tends to be very volatile in general (*), so a stabilized rawhide would pretty much boil down to the latest release anyways. Given that we pretty much already have this my reaction to this is please not another tree! * (we still need to see if no frozen rawhide changes this) Regards, Hans -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
