Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 11/22/2010 12:59 AM, Adam Williamson wrote:
> On Sun, 2010-11-21 at 23:04 +0100, Kevin Kofler wrote:
>
>> In short: Want higher-quality updates for previous releases? Then push
>> version upgrades wherever possible (even and especially for libraries, as
>> long as they're ABI-compatible or can be group-pushed with a small set of
>> rebuilt reverse dependencies)!
>
> I don't agree with this at all. It's just abusing a stable release cycle
> to try and make it into something it isn't.
>
> I should probably clarify where I'm coming from on this, as my position
> is probably more nuanced than my mails so far would seem to suggest. I
> don't necessarily think Fedora works best as a project which does stable
> releases every six months and supports at least two of them at a time
> (and often three). As I've written elsewhere, I'd very much like to look
> into the possibility of changing that.
>

<snip>

> It seems like what you want is actually not to have three releases at a
> time at all but to have one and update it constantly. And I actually
> rather suspect that would be a model that would work well for Fedora,
> and I'd like to look into adopting it.

Interesting topic (much more so then flaming about the updates policy)
I think that we can (and sort of do already) have both.

The way I see it, is we have:

rawhide (and for a part of the cycle Fedora #+1 testing)
Fedora #
Fedora #-1
Fedora #-2

Fedora #+1 is for people who want the bleeding edge
Fedora #   is for people who want the latest and greatest without too much
            bleeding
Fedora #-1 is for people who want it relatively safe and slow
Fedora #-2 Does not fit into this picture

So taking for example the much much discussed KDE rebases. I think that
doing a KDE rebase for Fedora #+1 is a no brainer, for Fedora # is fine
as long as it is properly tested and for Fedora #-1 KDE should NOT be
rebased. This also matches well with what the KDE people have been
reporting, were they can get plenty of testing on Fedora # but all most
none on Fedora #-1. I think that the few KDE users which remain on
Fedora #-1, do so because they appreciate some stability, and thus
should not get (a largely untested) KDE rebase.

This is also how I in practice deal with must updates for packages I
maintain I try to fix any serious bugs reported against Fedora # and am
a lot more conservative when it comes to Fedora #-1.

Note that Fedora #-2 does not fit into this view for things at all,
Fedora #-2 is meant to allow people to skip a Fedora release. But in
practice I think this works out badly, because a relatively new Fedora
release like Fedora 14 tends to still have some rough edges and get lots
of updates/churn (and thus possible regressions, despite our best effords).
This is not at a good point in its cycle to upgrade to for people who like
it stable (and sticking with 1 release for an entire year to me sounds
like liking it stable).

Where as the one which has already been out for 5-6 months (Fedora 13) has
seen most rough edges polished away with updates, and the updates rate will
have slowed.

So maybe it is time we dropped the support duration for a release from 13
to 11 months, and make clear that people should not skip releases.

Regards,

Hans
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux