-----BEGIN PGP SIGNED MESSAGE----- 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. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyjkUsACgkQeiVVYja6o6MK9gCcCanCbFhrzpWbiDqL2tu4XzWH JCEAoKDOboeQs4kYjSCRI88U7Dw9/ai0 =Reqd -----END PGP SIGNATURE----- _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
