On Fri, Feb 26, 2010 at 03:54:02PM -0700, Kevin Fenzi wrote:
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?
Since AutoQA is supposed to to behaviour testing of packages eventually,
how about a policy that says:
A stable update to Fedora must pass all AutoQA tests.
Then the granularity of stability can be adjusted by adding tests to
AutoQA. And I hope that only reasonable tests will be added to AutoQA,
e.g. a test that just ensures that a packages stays at version X would
not be one. But if it ensures that e.g. "yum-builddep foo.src.rpm"
installs all build deps of foo, it would be a useful test.
- 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.
If the maintainer receive more testing feedback, they probably won't
ignore it.
- 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.
Pushing less updates to F(current-1) is probably something many
maintainers can live with. But I have also heard of people using
F(current-1) and feeling like secondary users, because they did not get
the updates that F(current) got.
- 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
them.
There will always be updates in Rawhide that are not meant to be
consumed directly or without manual intervention.
Regards
Till