unfrozen repo somewhere?

[Ralf Corsepius]

On Mon, 2008-09-29 at 13:59 -0400, Horst H. von Brand wrote:
> 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?

> > >  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. 
My view: Not the too few testers, but an effect of an unhealthy workflow
and immature infrastructure.

> Splitting the
> user community into "rawhide rollercoaster", "beta testers", "waiting in
> the wings" doesn't help here (beta testers will be a tiny miniority).
Correct - These dedicated Fedora testers group can only iron out the
worst "brown paperbag class" bugs and misc. random bug - They will never
can compete with the amount of testing provided by the community. 

> The problems lie elsewhere:
> 
> - How do we recruit more beta testers?
My opinion: By changing the workflow, encouraging collaboration (e.g.
abandoning ACLs) and by replacing certain people who are known to ignore
bugs.

>  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.
Note: RAWHIDE vs. PRODUCT 

* Rawhide is TOO unstable to be usable
* Rawhide freezes are stalling the PRODUCT (Here: FC10 is killing FC9).

> > 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.
The situation would not change at all, because it's essentially the same
as what currently is happening. The only difference: Freeze would not
not block development.


> > 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...
Why should Fedora ship outdated stuff? To a community contributor, the
purpose of Fedora is to serve as medium to distribute packages and to
mutually share packages with other users.

So to answer your question: It's Fedora's job. If Fedora's
infrastructure is too inflexible to handle this, Fedora has failed.


> > > > - 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.
Good for you - Unacceptable to me, as shame  for Fedora.

> > > > - 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.
Please do yourselves the faviour and maintain some packages in Fedora. 

Then you'll probably notice the bureaucracy Rel-Eng has implemented and
how immature many things are. 

Ralf