REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Kevin Fenzi]

On Tue, 28 Sep 2010 18:45:11 +0200
Jaroslav Reznik <jreznik at redhat.com> wrote:
> 
> Ok - that's one problem - we sucks in selective updates and
> information for users.
>
> Other could be - change release scheme:
> 1. very similar to current one - rawhide, Fn, Fn-1
> * rawhide - really raw development platform
> * Fn - live release, similar to current state but more testing
> (proventesters, autoqa)
> * Fn-1 - do not touch, even more strict rules

Thats what https://fedoraproject.org/wiki/Updates_Policy already
attempts to impress on maintainers. 

> advantage - nearly no changes in our current workflow, compromise for
> more groups, Fn is live, hq updates but sometimes makes things more
> unstable, collateral damage... but slowing down in time (no big
> updates Fn+1 - 1 month?), once it hits Fn - it's really fresh but
> another 6 months of development - more stable, more bugfixes, happier
> users. With current policy - we have two frozen releases, no devs
> care anymore, dead and stable in terms - not touched not in
> functionality.

I'm not sure I follow... you mean rawhide is the way it is now, but F13
would be still open to major changes? 

> 2. big change
> * devel branches - now with GIT - every new feature should be
> developed in separate branch -> map it to development instance of
> Koji...
> * rawhide - merged devel branches with integration testing - fresh
> one, similar to current Fedora release - can be used by developers
> and power users 
> - sometimes broken by updates but they know how to deal with this
> breakage...

I'm not sure how this is different than current rawhide?

> * Fn - released one, strict update policy, service packs? - so faster
> update cycle? maybe

I'm not sure how this is different than the proposed stable updates
policy?

> 3. combination - I'd like to see devel branches, really and I like Fn
> & Fn-1 flexibility from the first example!
> 
> As I already said - I'm not against making Fedora better and more
> stable. I just think it's more complicated than just this "less
> updates = stable experience = more users" ;-)

I agree, but I don't think thats the entire thing thats being
proposed. ;) I think it's also more testing, more consideration of
_when_ we should do an update, etc. 

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/devel/attachments/20100928/e74f9735/attachment.bin