Hi, On 03/03/2010 10:30 PM, Doug Ledford wrote: > On 03/03/2010 02:27 PM, Tom "spot" Callaway wrote: >> Okay. This has gone on long enough. The signal is gone from the >> following threads: > > The signal is not entirely gone, although it is getting weaker. > >> * FESCo wants to ban direct stable pushes in Bodhi (urgent call forfeedback) >> * Worthless updates >> * Refining the update queues/process >> >> Accordingly, I'm marking those threads as Hall-Monitored. Please stop >> posting in them. If you have a concrete suggestion on how to improve >> Fedora updates, please write it in a wiki page, open a FESCo trac >> ticket, and they will consider it. > > The problem is that having a concrete suggestion of how to improve > fedora updates requires knowing whether we want a more stable update > cycle or a more semi-rolling update style. It would be easy for us to > carte blanch hand down an edict on this, but that would also be wrong. > This is a community driven distribution, and by my count the number of > people that stood up in favor of semi-rolling updates was not that > different from the number of people that stood up for stable updates (I > have something like 4 for semi-rolling and 6 for stable, but many people > didn't make their preferences perfectly clear, and this count is from my > admittedly worthless memory of those that were explicit in their desires). > I think the whole "stable update cycle" versus "semi-rolling update style" is too black and white. For core packages / major desktop packages clearly a "stable update cycle" is the right thing to do. But for packages which are more nice packages, the right thing to do may vary. What for example for a package which is not only added recently to Fedora, but came into existence recently in general. There might be some new upstream releases there which are not bugfix only but still very good to have (think pre-alpha -> alpha -> beta steps). Another example against having a hardcoded "stable update cycle" is multiplayer games. In quite a few online gaming communities, most of the community moves over to the latest release once it is sanctioned stable by upstream. If the client <-> server version need to be in sync (which they often do because they need the exact same maps), then this means that our "stable" version in F-released might become worthless pretty quickly as there are no or very little "stable" version servers available to play on. Also some upstreams do much much better QA then others, or are in general not as fast moving as others. In these cases it might make sense to do a "semi-rolling update style" for these packages, even if the upstream releases are not purely bugfix releases. So I think in the end this should preferably be left to the maintainer. And if FESco decides that a "stable update cycle" is what we want, can they *please* make this a not one size does not fits all policy. I would like to see a split somewhere, say included in standard <insert desktop environment here> install, versus the rest. With less strict checks at the *tool* level for the rest ? The idea here is that the policy prescribes a "stable update cycle", but leaves room for maintainers to make exceptions when they believe they have good reasons to do so, and that the tools (bodhi, autoqa) allow for maintainers for packages outside the "core" group to override the tool, without needing FESco / rel-eng permission first. Regards, Hans -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
