Updates Criteria Summary/Brainstorming

[Michal Hlavinka]

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
> things.
> 
> 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
>   criteria.

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 
disappointed again.
 
> * 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
> testers

this could help a little for some cases
 
> * Ask maintainers to provide test cases / test cases in wiki for each
> package?

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