Proposal for the future of Fedora

Kevin Fenzi kevin at tummy.com
Wed Sep 29 19:02:03 UTC 2010


On Wed, 29 Sep 2010 07:26:17 -0400
Stephen Gallagher <sgallagh at redhat.com> wrote:

> I would like to add my two cents to the new Updates Policy
> (https://fedoraproject.org/wiki/Updates_Policy), keeping in mind the
> new vision statement.
> 
> (Yes, I'm replying to my own original post to highlight the parts that
> are included, or not, in the new Updates Policy)

ok. 

...snip...

> > I also propose that the method of enforcement should be similar to
> > that of the current critpath system: Any bug marked "Enhancement"
> > must be given karma by a proventester in order to make it into a
> > released Fedora. Proventesters would be expected to understand the
> > guidelines set down as above. Failure to follow those guidelines
> > (green-lighting a new major XFCE release, for example) would have
> > to result in a loss of proventester status (with opportunity to
> > reapply in the future).
> > 
> 
> This was not addressed. I genuinely feel that there needs to be some
> gatekeeping policy to ensure that contributors don't ignore the
> Updates Policy (either willfully, accidentally or unknowingly). My
> view remains that proventester approval should be required for all
> updates marked "Enhancement". Bugfixes and security patches should be
> left as-is.

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. 

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

> > 2) We need a new policy regarding branching. Currently, the new and
> > upcoming version of Fedora is branched from Rawhide at the moment
> > that development begins on it. This needs to change.
> > 
> > Instead of branching from Rawhide, I think Fedora N+1 should be
> > branched from Fedora N. Rawhide should remain an exciting
> > think-tank of in-development features, but we should always plan
> > for Fedora N+1 to be a more stable environment. In this way, it
> > should be first of all easy for developers to upgrade their system
> > into Fedora Branched.
> > 
> 
> This is, I feel, the most important part of my proposal here. If
> nothing else from this email is addressed, I think this needs to be.
> 
> Rawhide CANNOT function as a rapid development environment if it is
> regularly Branched. There are many projects that benefit from the
> ability to use Rawhide for long periods of time to stabilize a new
> feature before it belongs in a stable release.

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

> 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? 

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

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20100929/c61fd88a/attachment.bin 


More information about the advisory-board mailing list