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.
Make rawhide consumable as a semi-rolling release itself.
Reasons:
1) Most importantly, it's a means of satisfying both groups of people in
the Fedora developer community and leaving none behind.
2) It saves developers time and effort. This is actually the least
burdensome method of satisfying both groups of people inside Fedora.
The whole 2 update stream approach increases the load on maintainers,
while this approach reduces the load on maintainers as a maintainer gets
to consider a Fedora release "done" when it goes out the door with the
exception of fixing any security or important bugs in that release. For
many packages, this means the maintainer will actually not have anything
to do in those releases and they can concentrate solely on devel (this
is obviously not true for big and highly used packages like thunderbird,
firefox, gnome, kde, they will always have bugs and updates needed, but
many other packages, especially smaller leaf packages, may never need a
single update during a stable release lifetime).
3) It conserves resources (drastically so) on the fedora infrastructure
and mirrors and reduces bandwidth needs greatly.
4) It helps Fedora scale (from a repo resource consumption standpoint at
least, but also in terms of developer time for the packages that won't
need lots of stable updates).
5) It would be less labor intensive to implement and work flows would be
simpler than the two update stream, ala Mandriva, approach to satisfying
everyone.
Before I get into the technical implementation part of the proposal, I
want to take a moment to step back and mention something to both sides
of the camp that have been involved in this discussion so far:
We have established, beyond any doubt whatsoever, that there are users
of Fedora that expect, demand, and need a stable update stream.
Ignoring those user's needs by saying "why can't we just stay as we are"
is tantamount to blatantly ignoring their cries for change/help,
trivializing their issues, and pushing them aside as unimportant.
We have established, beyond any doubt whatsoever, that there are users
of Fedora that expect, demand, and use fedora *because* they get major
updates in the middle of a release. Ignoring these users needs by
saying "rawhide is ==> way" without first doing what is necessary to
make rawhide usable and consumable is tantamount to blatantly ignoring
the untenable nature of your suggestion, trivializing their wants and
issues, and pushing them aside as unimportant.
So maybe we can choose to put the rhetoric that has flung around in this
discussion down, stop trivializing our fellow Fedora community member's
issues, and work together. After all, that's what being part of a
community is all about. If we can agree on a policy that satisfies both
groups of people, then that can inform and guide our technical
implementation discussions, keeping in mind that a failure of the first
draft of the technical implementation is not grounds to throw out the
policy, merely grounds for more work on the technical implementation ;-)
Technical implementation proposal:
1) Make rawhide consumable.
A) Create rawhide-unstable. Any time a known disruptive change is
being worked on, it should be built here by the developer. In
addition, add rpmdiff checks to all builds from devel into
dist-rawhide and if any of certain rpmdiff checks trip positive,
move the package from rawhide to rawhide-unstable. Additional
checks can be added as AutoQA gets into full swing, and so we can
add more ways to catch breakage and move things to rawhide-unstable
as needed.
B) Non disruptive changes go into rawhide directly, and on a regular
basis we run a compose on the rawhide tree to create install
disks/images for use. I suggest once a week we recreate the
images.
C) On a regular basis, we have a flag day to move items from
rawhide-unstable to rawhide. I originally said as-needed in my
first proposal, but on more reflection I would like to suggest
we make this a regular scheduled event on a monthly basis. In
this way we have 6 regular rawhide-unstable==>rawhide checkpoints
between each release cycle, and we can make the last one or two
prior to the next fedora release do double duty as both the
normal checkpoint and the fedora alpha/beta freeze. This also has
the side benefit that people working on major changes, like say
anaconda install updates, have more points at which they can get
their code into a consumable segment of the repo and start getting
feedback.
D) Anyone who likes that rawhide allows them to develop directly
on their OS can simply enable the rawhide-unstable repo in their
yum configs. Like enabling updates on a regular release, it
would inherit from rawhide and also include all the distruptive
changes. This makes a system with rawhide-unstable enabled
identical to rawhide today.
E) Without rawhide-unstable, you get a semi-rolling release that
allows for regular checkpoints to introduce disruptive changes,
soname bumps, etc. only on a more frequent basis than the current
fedora release cycle. It is hoped that by having this higher
frequency, disruptive changes in the semi-rolling release that is
rawhide can be handled more easily. Kind of along the lines of
easier to deal with by taking more, smaller bites instead of huge,
hard to swallow bites.
2) Make Fedora releases adhere to a stable release policy. This already
covered rather well in proposals put forth by other people. Mike
McGrath's snapshot proposal and Matt Domsch's Slowing rate of change in
older releases proposal are the two I would pair with my proposal in
order to satisfy both groups. I don't see any reason to rehash them here.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
