[Mageia-dev] Finalizing update process

Thu Jun 9 01:25:16 CEST 2011

Le jeudi 09 juin 2011 à 00:53 +0300, Ahmad Samir a écrit :
+> On 8 June 2011 23:40, Anssi Hannula <anssi.hannula at iki.fi> wrote:
+> > On 08.06.2011 23:23, Ahmad Samir wrote:
+> >> On 8 June 2011 21:45, Samuel Verschelde <stormi at 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
+
+