FESCo wants a more sane updates policy (feedback requested)
kevin at scrye.com
Fri Feb 26 22:54:02 UTC 2010
I'm putting my thoughts here... but this is again one of those threads
that has about 500 forks and people nit picking back and forth, so I am
never sure where to do a general reply. ;)
First some background:
a. There is no policy to discuss here, as we don't yet have a proposal.
I would expect after a draft is constructed it would be posted here for
feedback and more input.
b. Given a, I would say people should stop posting to this thread. If
you have a better updates policy in mind, perhaps you could draft up a
proposal for what you think it should be? Or wait for a real proposal
to comment on?
My thoughts (not speaking for fesco or anyone else):
- I think we are breaking our "stable" releases too much, and also
pushing them too many bits that they don't need/want. I've seen this
feedback a number of times from the various support channels, (irc,
forums, mailing list).
- I think educating our maintainers to be more carefull or get more
testing feedback has not worked so far, nor is it likely to moving
forward. We simply seem to lack the communications channel to do so.
- I think perhaps a more lifecycle like thing could help our users know
what to expect. Currently, they don't. They could get a major version
bump at any time, in a older "stable" release. I have talked to users
who are are f11 still because they think it will be "most stable" but
then are dismayed with how many updates they get.
- Perhaps we could look at ways to make rawhide more day to day
friendly. I think the autoqa stuff might help here. If those people
that needed the very newest version of everything could use rawhide,
perhaps we could target the stable releases more to those that want
- From some of the comments here I am getting the idea that people
would like for us to move to a "2 tree" setup. Ie, "rawhide" and
"release". Things get tested in a cursory manner in rawhide, then get
pushed to release? Is that right? Perhaps someone could write up a
proposal for how such a flow could work? Do you think we would have
any users left in such a world?
- If stable pushes were more restricted, perhaps that would get us more
testing? If someone required a newer version and could easier
install/test from updates-testing and provide feedback, don't we all
win? Perhaps we could have PackageKit/yum say "you have the latest
stable version of foo, but foo-2.0 is in updates-testing, would you
like to test it and provide feedback?
- For those things that don't have many users, we could allow a time
based approach. keep the update in testing for a few weeks and then
it can go to stable with no -karma. I admit I run with
updates-testing enabled here, but usually only find time to provide -
karma. I have however done that a fair bit.
- This is a balancing act i think, we don't on the one hand want
everything always updated like rawhide in a stable release. On the
other hand we don't want to only provide security updates and nothing
else. What do our users expect here? I would argue that given the
decline in downloads and such they are clearly saying the status quo
is not what they want.
Anyhow I think this thread is mostly hot air unless there are specific
proposals or concrete feedback. Please write up a detailed proposal, or
wait and provide feedback when we have such? Or at least post new
ideas... not 'he said, she said' back and forths.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100226/0708b721/attachment.bin
More information about the devel