On 9 June 2011 01:25, Michael Scherer <m...@zarb.org> wrote: > 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 > >
Yes, but I was talking about the actual submitting to */release, not fixing the package itself. IIUC the submission rights will be restricted to the Sec team. -- Ahmad Samir