Proposal for the future of Fedora

Stephen Gallagher sgallagh at
Wed Sep 29 19:19:39 UTC 2010

Hash: SHA1

On 09/29/2010 03:02 PM, Kevin Fenzi wrote:
> Well, I can't speak for fesco, but speaking for myself, I wanted to get
> a policy in place, and then get metrics in place and only THEN see what
> enforcement we need. Hopefully most maintainers will do the right
> thing, but yes, we may need some enforcement. 
> I don't know that requiring proventester karma for enhancement updates
> will really do it. Maintainers can just mark things as bugfix (when
> they contain both bugfixes and enhancements). We don't really have any
> guide for when one should be used over the other in those cases. 

Yes, they can. However, in this case they would be KNOWINGLY violating
the package policy and trying to sneak around it. I think most people
would willingly mark their submissions appropriately when possible.

> So, ideas for enforcement are welcome, but I think it was still
> important to get the policy out there. 

Sure, that's completely fair. I just wanted to make sure the
conversation doesn't get lost.

> So, just to clarify... you mean for those things that take longer than
> 6-9months to stabalize? Do we have things like that regularly in the
> open source world? Things planned for release longer than that ahead
> (and are buildable)? (Note that gnome3 was not in this bucket, as it
> was planned for release in time for f14. Slips will sometimes happen). 

Not necessarily. I'm talking about having some place that it's safe to
drop pre-release builds for new functionality without necessarily having
to plan around the stable release schedule. We have Branched for that
(which should be branched as soon as the previous Fedora is declared Gold).

The projects I'm talking about here are the ones with higher potential
impact. Things like GNOME 3, or the next KDE release.

It doesn't need to be only projects that need 6-9 months to stabilize,
but it DOES need to be those that need more then N-6 months (the time
between the current moment and the next branching).

Projects whose upstreams don't neatly line up with a Fedora cycle belong
in Rawhide until it's time to merge them to Branched.

>> Currently, such contributors have only two options:
>> 1) Keep an eye out for when Rawhide is going to branch and unpush
>> their packages until after the branch is done, then re-create them.
>> 2) After the branch is done, bump the epoch on their package in the
>> Branch and revert it to a known good state (or pull it completely from
>> the Branch, if it's a new package)
>> Both of these approaches are highly disruptive to a working
>> development environment.
> Sure, but do we really have projects that need longer than a 9 month
> time in rawhide? 

I can think of several examples: desktop environment major release
versions, major upgrades to core libraries like glibc (eglibc?) or d-bus

In the not-too-distant-future I myself am going to be starting work on a
project for SSSD 2.0 which will involve major work to integrate with the
various desktop environments. I fully expect that this will take more
than one Fedora release to stabilize.

> As an example here, Xfce has been working on 4.8 for longer than that. 
> However, I'm not sure it all even builds or that any plugins work with
> it. I see no reason to pull it into rawhide until there's a clear idea
> when it will be released. Is there advantage to having these "not
> finished at all yet, but I hope someday it is" projects in rawhide?
> Sounds like almost a 'rawerhide' would be good for them...

I think we just have varying definitions of what Rawhide is/should be.
In my mind, your vision of rawhide belongs in Branched.

And as I said, I'm not advocating rawhide as a dumping ground for "not
finished at all". Rawhide as a whole should be designed to be an
installable platform for building the Next Big Thing.

I think Rawhide's motto needs to be "Release early, release often". As a
middle-ground, perhaps we can include a policy to require reversion of
packages that aren't being maintained in rawhide.

>> I think that it really only makes sense for development to branch from
>> the previous STABLE release (plus updates). It should be the
>> responsibility of package maintainers to manually move rawhide
>> packages into the Branch at that time. Then they can more easily
>> decide when development is truly ready for inclusion in a stable
>> release.
> I don't think this is a good idea off hand. This makes rawhide an
> island. "Toss whatever you like in rawhide, it never gets released",
> instead of "You are putting $foo in rawhide, so you think it will be
> released in time for the next fedora release". 

Again, I think you're talking more about my vision of what Branched
should be.

So I'm looking at this breakdown:

Rawhide: Work-in-progress packages for the Next Big Thing
Branched: Packages being stabilized for the next stable release
Released: Stable packages following the mostly-bugfix-only update policy
(possibly with the enforcement rules suggested above)

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the advisory-board mailing list