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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
