To semi-rolling or not to semi-rolling, that is the question...

[Kevin Kofler]

Doug Ledford wrote:
> 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.

And let me reiterate my objections, because you asked for it. :-)

> 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.

Yet it is the only solution which really satisfies both groups of people. 
Stabilizing Rawhide is pretty much a lost cause. What your proposal further 
down does is actually introducing an intermediate stream à la Debian 
testing, which comes with a lot of extra maintainer work as well.

> 3) It conserves resources (drastically so) on the fedora infrastructure
> and mirrors and reduces bandwidth needs greatly.

How so? You're still adding an extra repo.

> 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.

Uh no. It's just saying that there are dozens of distributions out there 
already doing exactly that, they should just pick one. Fedora has never 
worked that way, why should we do so now?

And I also dislike the usage of the term "stable" for this purpose, as it 
implies our current updates are "unstable", which to most users means 
"crashy".

> 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.

Sure, but making Rawhide consumable is a lost cause (and is in fact not what 
your proposal is actually trying to do).

> 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.

At this point you've created 2 rawhides, which already means 2 repositories 
etc.

>   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.

(As Till Maas already pointed out: ) How do we verify these changes as non-
disruptive without a testing repo (which would be a THIRD rawhide)?

Handling the 2 separate buildroots could also become fun, especially if we 
try to use rawhide-unstable as the testing repo (which isn't that great an 
idea because it won't allow easily testing the changes with the set of 
packages actually in rawhide-consumable, but which is the only choice in the 
absence of an additional rawhide-testing). We'd probably have to rebuild 
packages to move them into the consumable repo, leading to extra work (and 
thus tempting the maintainer to just leave the stuff in rawhide-unstable, 
which will lead both to unhappy early-adopting users and to huge dumps of 
semi-broken packages on flag day, we've seen exactly the latter happening 
again and again when the one Rawhide switched from Fn to Fn+1 in the pre-NFR 
days) and potentially invalidating part of the testing.

>   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.

This means we'd have 6 times as many flag days for disruptive changes than 
for a model based on non-conservative updates to stable releases. I agree 
with Till Maas that this is undesirable. Once again: what I, and I think 
most others in the "updates should be semi-rolling" camp, want is the new 
features that DON'T break anything, WITHOUT the breakage.


An additional issue I see with the proposal as a whole is that I'm not 
convinced that, even if all the problems I pointed out above are solved, 
this will actually lead to something more consumable. The branched F13 right 
now is quite similar technically to your "consumable rawhide" and it even 
has the additional testing repo I hinted at, but it's still not something 
I'd want to run in production! For example, PackageKit 0.6 just became 
usable at all very recently. Now of course this may be due to the fact that 
there was nothing like rawhide-unstable before the branch event, but let's 
face it: we'll still always have stable releases to care about. At feature 
freeze (or on the last flag day before feature freeze), the disruptive 
changes which are targeted to be in the stable release WILL get merged, even 
if, when considering rawhide-consumable on its own, it'd be better to wait 
for a later flag day. And so we'd also have stuff like PackageKit 0.6 in 
rawhide-consumable. Unless of course you want to branch releases directly 
from rawhide-unstable and have rawhide-consumable be completely separate, 
but I don't think that particular idea is that great either.

Rawhide is for development of future stable releases, so we import things 
like prereleases of the KDE version which will ship in that future release, 
which is essential so it gets testing by somebody, but which shouldn't be 
dumped on non-tester users, even early adopters. You're trying to give it a 
dual use, to also target early-adopting users, but that dual use is 
inherently flawed and an extra rawhide-unstable does not fix that, it just 
introduces extra work.

        Kevin Kofler