Le jeudi 09 juin 2011 à 00:53 +0300, Ahmad Samir a écrit : > On 8 June 2011 23:40, Anssi Hannula <anssi.hann...@iki.fi> wrote: > > On 08.06.2011 23:23, Ahmad Samir wrote: > >> On 8 June 2011 21:45, Samuel Verschelde <sto...@laposte.net> wrote: > >>> Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : > >>> > >>>> IMHO, rejection reasons: > >>> > >>>> - The sec team doesn't think the update fixes a serious security > >>> > >>>> vulnerability; so it's not updates but backports > >>> > >>> What about bugfix updates ? I guess fixing a bug is a valid reason for an > >>> update, like it was in Mandriva's updates. > >>> > >>> Regards > >>> > >>> Samuel > >> > >> Right, I probably phrased that one wrongly; I meant: > >> fixes a serious bug, e.g. crashing, segfaulting > > > > I don't think we should exclude non-serious bugs :) > > > > Depends, overworking the sec team doesn't look like a good aspect... > (that's why I liked contrib in mdv, I could push an update any time, > without having to go though the bug report -> QA -> Sec team loop).
Well, I didn't asked to secteam to do anything except managing the security aspect : - finding CVE - finding patch ( with the help of maintainer ) - finding test and fixes But the building and updating should be done by maintainer, as this would scale better. Let the security team focus on the security aspect, and be there as a help for maintainers and viceversa. We shouldn't overload the secteam, while maintainers are here for that :) One of the problem at Mandriva was that security and stable updates were quite disconnected from maintainers, and so it didn't scale well. It didn't scale because people didn't know security procedure ( it was not part of the expected curriculum of a packager, and often was done without them implied ), it didn't scale because security was only for a restricted set of salaree taking care of everything on separate systems. I think we should focus on having : - a system using already know procedure ( ie regular build system ) - make sure that taking care of update is something done regulary as part as packager duty ( after all, that's the whole part of being maintainer ) > > (or version updates in some cases, like firefox/opera/flash or updating > > an rc/beta version to a stable one, and maybe some online games that are > > useless unless on latest version) > > > > I agree, (except for the games part, nowadays if it's less than 4GB > it's not really a "game"). I guess we can start with a list of exception : - stuff that should be updated to latest version, because the security support for older releases ( firefox, chrome ) is too hard -> we update to latest version if there is no regression and a strong reason to upgrade ( severe bugfixes, security issue, breakages ). Exception of this category should be very expectional - stuff where there is strict bugfixes only release ( postgresql ), or update to a stable version ( which should be a bugfix only release when compared to beta/rc :) ) -> we upgrade to stable ( for rc/beta ) -> we do version update if it is bug fixes and if the packager is ok with it ( and if the rules of the bugfix branches are clearly documented ) - everything else -> only minimal patches The question of game is still open, ie, should it go in 1st category, or should we have different rules to see what should be there or not ? I guess this would only be for networked game ? > Maybe the sec team should only work on sec fixes, and there should be > a sub-group of the sec team that handle the not > CVE|crash|segfaulting|buffer-overflow updates. segfault, crash are the duty of packager, as well as wrong requires or anything. -- Michael Scherer