kevin at scrye.com
Sat Sep 25 19:03:08 UTC 2010
On Thu, 23 Sep 2010 16:58:39 +0200
Jaroslav Reznik <jreznik at redhat.com> wrote:
> Not a very latest thing but more like - more useful thing. Because
> some useful "user experience" changes could lead to better user
> experience even changing slightly the old one. It's not easy to catch
> this in policy. I like the idea, I understand why we want it - I want
> it too, why we need it, it's more relaxed than the first proposals
> leading practically to frozen, dead and unmaintained releases. But
> still there should be more space for packager's decision and of
> course upstream - upstream releases for some reason.
Sure sometimes things change for the better... a new UI is nicer than
the old one. The thing is that most people don't want that to happen on
some random day in the middle of a stable release. This would cause
them to stop doing what they wanted to do to learn the new UI. Much
better when it's in the new Fedora release where they realize that they
need to learn how the new version works before using it.
> stability proposal has to be coupled with a new release scheme - not
> just update policy but also release schedules, what we are going to
> call "release", how often (9 months? branch every 6 - we we talking
> with Jesse a few minutes ago), how big changes we want in a new
> release etc... I'm not sure it's going to work without deeper changes
> here too.
Feel free to put together a detailed proposal on a new release
cycle and we can take a look.
I've often thought a 9month cycle (18 or 19 months supported) would be
nice and give us more time, but then we are misaligned with a number of
projects upstream that are on a 6 month cycle, and also, we don't
release at the same time(s) each year, resulting in hitting holidays or
the like. :(
I don't know a solution, but if you come up with one, please do let me
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100925/7835e54b/attachment.bin
More information about the devel