[HALL-MONITORED] Update threads are now hall-monitored

Hans de Goede hdegoede at redhat.com
Thu Mar 4 09:08:28 UTC 2010


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


More information about the devel mailing list