unfrozen repo somewhere?

[Horst H. von Brand]

Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Mon, 2008-09-29 at 00:37 -0400, Horst H. von Brand wrote:
> > Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote:
> > > > Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote:
> > > > > > Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:

[...]

> > > > > What I would like to see it Rel-Eng to adopt the development
> > > > > principles, most other developments apply:
> > > > > 
> > > > > Decouple "product development" (here: FC<N+1>) development from
> > > > > bleeding edge "unstable/experimental" "head development" (here:
> > > > > rawhide).

> > > > Needs more hands. Starves the "product development" of developers and
> > > > testers.
> > 
> > > I don't see this - To the contrary. I feel the current model is driving
> > > away developers and testers, esp. packagers.

> > Any hard (or even mushy) data to support this?

> I am only speaking for myself here.

I see.

> > > >  Was the idea in Linux before 2.6, was abandoned for exactly the
> > > > above reasons.

> > > ... but it is the idea which is being applied almost anywhere else.

> > Examples?

> ... GNOME, GCC, binutils, gdb.

> > > Ask yourself: Is the current development model in Fedora a success?

> > Need to define what "success" means... if it is keeping a very popular,
> > solid distribution moving forward, and gathering more packages, I'd have to
> > say it is.

> > > I don't think so.

> > How do you define "success" then?

> In the sense of "development model assists to achieve a functional and
> stable product".

> >  Where is Fedora lacking?
> 
> 2 fundamental issues:

> * Stability: Initial Fedora CD/DVD releases tend to be pretty buggy and
> often are unusable. At least to me, most Fedora releases so far only
> have reached a point of "acceptable quality" several weeks after
> release.

OK. Need more testers, more shaking out (and fixing!) bugs. Splitting the
user community into "rawhide rollercoaster", "beta testers", "waiting in
the wings" doesn't help here (beta testers will be a tiny miniority).
The problems lie elsewhere:

- How do we recruit more beta testers? Give them a "I was a beta tester"
  badge of sorts, for example, listing all people who reported a bug in
  beta in a "Thank you for testing Fedora XI" page? Other ideas?
- Make the beta process more effective. Make it last somewhat longer (so
  there is more testing)? Define a set of "standard tests" that any user
  can run on the beta and report back with detailed configuration/setup? 
  Perhaps there should be more in the way of regression tests for each
  package?

> * Support to packagers/ease of use of the infrastructure:
> One detail amongst many: The freezes are a major handicap to packagers.

I just don't see how. One the one hand you complain that rawhide changes
too fast to be a reliable platform on which to develop; on the other hand
you don't want it to slow down ever, not even to shake out last bugs.

[...]

> > > - Fedora releases essentially are rawhide snapshots. Packages from
> > > rawhide automatically become "stable" (Lack of "rawhide/testing"). E.g.
> > > I have package upgrades pending, I currently don't want to push to
> > > Fedora, because I fear them to be too unstable for a product.

> > Then they should go to rawhide?

> If Fedora was using release branches, then this would be a possibility.

Or you could wait a week or so, or (if /really/ urgent) push it upstream.

> I'd push these packages to rawhide now, and would push them to an FC10
> release branch when having gained confidence these upgrades are stable
> enough for FC10.

And next to nobody will test what is in the beta, as we all follow
rawhide. What if the changes turn out bad, and you have to rely on what is
in FC10?

> The current development model causes me to withhold these upgrades to
> avoid endangering FC10.

Rightly so.

> => These upgrades with likely be missing in initial FC10 and may (or may
> not) be added to FC10 later (or never).

Tough. They will be in FC11 then. It's not that that will take three or
four years...

> >  Go into your local,
> That's what they do now => Little attention, little testing.
> => These upgrades with likely be missing in initial FC10 and may (or may
> not) be added to FC10 later (or never).

Why /must/ they be in FC10? It isn't exactly the last of the line...

> == Missed opportunities.
> 
> > > - Fedora's release process starves package development. E.g. I have
> > > several (upstream) package upgrades pending, I can't push to Fedora
> > > because to the freezes are permanently interfering.
> > 
> > Please elaborate. Freezes are far in between, it would be phenomenal bad
> > luck if many important upstream just happen to fall into those. And those
> > can presumably be applied after the freeze is lifted.

> The problem is: Neither a packager's nor an upstreams' workflow are
> necessarily synchronized with Rel-Eng's workflow or Fedora release
> cycles (And if they are, things occasionally tend to get worse.)

So what? There has been whining that Gnome version something wasn't
included, or that GCC missed the deadline, or KDE, or... and that was
smoothed out by including them later (if stable enough) or just in the next
round (if not). Works as designed for me.

> > > - rawhide is too volatile to be usable for many testers, esp. packagers
> > > testing their packages.

> > Heck, rawhide is stable enough for me to use as a regular workstation (with
> > some precautions), how would that be /so/ different than deoing development
> > work?

> A matter of personal objectives: You probably are working on the "Fedora
> distro". I am working on applications and am using Fedora as a vehicle.

No, Im currently /using/ Fedora as a workstation for day to day use, doing
a bit of development and some testing of bleeding-egde packages. Plus
reporting whenever something blows up, and backtracking.

> > > - The current process introduces a bloated bureaucracy to work around
> > > the side-effects of "not-branches".

> > Please elaborate. I'm sure the people involved would love to get that
> > workload diminished...

> /me feels a lot of the bureaucracy and other churn Rel-Eng is imposing
> on packagers actually is them playing with symptoms of them not applying
> release branches.

Please explain with apples and oranges /what/ the excessive bureacracy
consists of, and how exactly having to juggle four branches (FC8, FC9, FC10
beta, rawhide) instead of three (FC8, FC9, FC10 beta) helps in reducing
overhead and streamlining the release process.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513