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: > > > > > > > > I understand why rawhide should be frozen at some points, > > > > > > > Openly said, I don't understand this. To me, these freezes are a > > > > > > defect in Rel-Eng's procedures, which could easily be overcome, > > > > > > if they wanted to. > > > > > > What Rel-Eng wants is that the rawhide snapshot that Is To Be > > > > > Fedora-<next> gets beaten to a pulp by us rawhideans. Yes, I'd also > > > > > like for the rollercoaster ride to continue, but there is no way > > > > > around that us crazy bunch needs a little gentle leading to help > > > > > out stabilize the next release. Plus I can imagine that most (all?) > > > > > developers are concentrating on that job, so there are not many > > > > > hands free to work of pushing the envelope forward in any case. > > > > > 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. > > > 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. * Support to packagers/ease of use of the infrastructure: One detail amongst many: The freezes are a major handicap to packagers. > No, this is not > just making noise, I'm really interested in the answer. Neither am wanting to make noise. I am simply trying to raise attention to what I consider to be a fundamental problem in Fedora. > > - 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. 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. The current development model causes me to withhold these upgrades to avoid endangering FC10. => These upgrades with likely be missing in initial FC10 and may (or may not) be added to FC10 later (or never). > 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). == 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.) > > - 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. > > - 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. Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
