On Mon, 2008-09-29 at 13:59 -0400, Horst H. von Brand wrote:
Ralf Corsepius <rc040203(a)freenet.de> wrote:
> On Mon, 2008-09-29 at 00:37 -0400, Horst H. von Brand wrote:
> > Ralf Corsepius <rc040203(a)freenet.de> wrote:
> > > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote:
> > > > Ralf Corsepius <rc040203(a)freenet.de> wrote:
> > > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote:
> > > > > > Ralf Corsepius <rc040203(a)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