On 01/27/2011 10:24 AM, ext Thomas Perl wrote: > 2011/1/27 Riku Voipio <riku.voi...@nokia.com>: >> For new versions, the set of checks should still be shorter and less >> votes needed. Basically the only check to be done is "has the new >> version any regressions compared to the version already in extras". > > So a rouge developer could just upload a well-behaving tool at the > first time (where a more thorough check takes place and more votes are > needed), and then upload another release later on with some dangerous > code which sets the device on fire, and this update does not need so > any votes?
Read again. I did not say "no checks" or "no votes" for upgrades. I said *less* checks and *less* votes. > It does not even have to be a rouge developer - just think > about the Debian SSL vulnerability. And you think that our current 10 voters process would catch *that*? You can't complain that we should not go down 5 votes on upgrades when 10 testers wont catch bugs like that anyways.. > I'd consider a normal update as important as a new release. There is a big difference - when new version is uploaded, there is already a version in extras. Thus there is only one question that needs answering - is the version in extras-testing better or worse than the in extras. If there is bug in the version in extras, people will be installing the buggy version as long as the new version drags it feet extras-testing. > If we were > doing some kind of fast-tracking for minor updates, we should at least > show a debdiff of both source packages somewhere in the web UI, so > that a fellow developer can check what source code changes are in > there, and have a better understanding of the changes (it should be > obvious from the source diff what changes there are, and if they are > minor and really just aim to fix a bug). Showing debdiff on new versions would be a good idea. Still, I'd also go with less votes (like 5) to encourage people to upload bugfixes often. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
