Updates Criteria Summary/Brainstorming

[Kevin Kofler]

Michal Hlavinka wrote:
> 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.

+1, so true (and sad). :-(

(BTW, it's not just your country, they just get it dictated from the EU. 
It's the same all over Europe, and it's worse on the other side of the 
Atlantic.)

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

Indeed, these new PITA policies are very demotivating!

> 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).

Indeed. I think it's a big mistake to provide only second-class support for 
Fn-1. The assertion that that's what the people on Fn-1 want is just 
unfounded, based on a misunderstanding of why people use Fn-1.

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

Right, and the big point there should be that a bug which can corrupt mail 
folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY 
testing requirement there is a failure.

>> Other concrete ideas?
> 
> let maintainer decide, punish (enforce any policy) only those maintainers
> who breaks something, not all innocent group

+1!

        Kevin Kofler