FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-03-2010, 10:42 PM
Doug Ledford
 
Default Update threads are now hall-monitored

On 03/03/2010 06:14 PM, Toshio Kuratomi wrote:
> https://fedoraproject.org/wiki/Release_Lifecycle_Proposals
>
> Several people have made proposals which are listed here. I know of several
> others (for instance, jresnik's proposal for different F-Current and
> F-Current-1 update styles) and your own.

I will probably both send my proposal here and post it there. But it
won't be until later tonight, I have to leave for about 5 hours now :-/

--
Doug Ledford <dledford@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 08:08 AM
Hans de Goede
 
Default Update threads are now hall-monitored

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 01:08 PM
Chris Adams
 
Default Update threads are now hall-monitored

Once upon a time, Hans de Goede <hdegoede@redhat.com> said:
> 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.

Well, but reading this thread, it obviously isn't "clearly [...] the
right thing to do." I think it is, and you think it is, but that is an
opinion and many don't share it.

> 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).

I do think that more people should work like how GNOME, Firefox, and
some other things have been handled in the past, where the upstream
release cycle doesn't quite match Fedora's. There have been a few cases
where an RC or late beta has been put into Fedora during release
testing, when the final upstream release is not scheduled to be released
until around or just after the next Fedora release. As soon as the
"gold" bits come down from upstream (and they can be tested!), they get
pushed as an early update for Fedora.

For example, OpenSSH is working towards the release of 5.4p1. I would
like to see a snapshot in F13 for testing ASAP, so it can get wider
testing. Now, it is likely that OpenSSH 5.4p1 will ship long before
F13, but even if it didn't, I think it would be safe to ship a snapshot
and push 5.4p1 as soon as it is released.

--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 01:47 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org