On Tue, 28 Sep 2010 18:45:11 +0200
Jaroslav Reznik <jreznik(a)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