Updates Criteria Summary/Brainstorming
mhlavink at redhat.com
Mon Nov 22 10:03:45 UTC 2010
On Saturday, November 20, 2010 23:35:43 Kevin Fenzi wrote:
> ok, I dug through the devel list for the last month or two and wrote
> down all the various ideas folks have come up with to change/improve
> Here (in no particular order) are the ideas and some notes from me on
> how we could enable them. Please feel free to add new (actual/concrete
> ideas or notes):
> * Just drop all the requirements/go back to before we had any updates
I like this idea, but I'm pretty sure this won't happen. I don't like the
bureaucracy you can see all around you. Fixing problems caused by individual
failure (or individual's failure) with new policy/law does not make happy
contributors/people. This is the exact behavior of Civil Aviation Authority in
my country - after 50 years of no problems there is one a***ole that kills
himself because of ignoring physics and self-preservation, as result all sane
normal people have to do more paperwork and are more restricted. The only
result is pilots are more and more fed up every year. And know what, there are
still people willingly breaking the rules so it does not solve anything.
Another comment: When I started to work for Fedora, I tried to do my best. You
know, there are some comparisons of OSes and distributions. One of the
comparisons being "How many days OS was vulnerable (with known exploitable
security bug)". So when there was new CVE-XXXX-YYYY bug, I tried to fix it as
fast as possible, because I wanted to make Fedora The Best Distro. But what
happened after I fixed this bug? It took whole week before new build was
tagged. Should I work hard if there is no visible result? I was disappointed.
Now, packages are tagged quickly and reliably, great improvement (thanks to
everyone who helped with this). But again, after things were better we have
new policy that delays all bug fixes from being delivered quickly and I'm
> * Change FN-1 to just security and major bugfix
> This may be hard to enforce or figure out if something is a major bugfix.
This idea would make users less happy, at least from what I see.
I manage a few Fedora systems for my friends/relatives who have almost
no IT knowledge nor they can use English. They don't care about open-source
and other "freedoms". They use Linux just because it's free and usable (they
always compare it with m$ windoze they used before). In real world, bugs
happen, they don't care too much about bugs in sw, if there is visible
progress. If they found a bug, they complain to me and I file it in bugzilla.
Once the bug is fixed, I report these wonderful news to them and they are
really happy. But... remove the "bug fix delivered to Fn-1" and they won't be
happy, in fact they would think that Linux sucks. Restriction to most critical
bugs only is not enough. And no, updating all machines every 6 months is too
much disturbing (for them) and time consuming (for me).
> * allow packages with a %check section to go direct to stable
%check can be simple, %check can be complex, but where would you draw the
line? Also very limited number of GUI apps has %check (only guess)
> * setup a remote test env that people could use to test things.
I don't think this would make significant difference. People don't test packages
because they don't have time, they are lazy, they don't know how to test it or
they are just consumers (not enough IT/english knowledge).
> * require testing only for packages where people have signed up to be
this could help a little for some cases
> * Ask maintainers to provide test cases / test cases in wiki for each
this could help, but it's not always possible to add these test cases. One
example: imap server package - new bug that can corrupt mail folders in some
circumstances. Maintainer updates package and sets 'type=bugfix' in bodhi, but
not always it's possible to write down any test case. It's still a bug fix and
it's better to be delivered sooner than wait if anyone out there get's his
mail folders corrupted. Actual policy does not help proactivity.
> * reduced karma requirement on other releases when one has gone stable
better than nothing :)
> Other concrete ideas?
let maintainer decide, punish (enforce any policy) only those maintainers who
breaks something, not all innocent group
More information about the devel