On Mon, 2008-09-29 at 13:59 -0400, Horst H. von Brand wrote: > Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > On Mon, 2008-09-29 at 00:37 -0400, Horst H. von Brand wrote: > > > Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > > > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote: > > > > > Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > > > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote: > > > > > > > Ralf Corsepius <rc040203@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
