[Mageia-dev] Finalizing update process

Thu Jun 9 01:40:15 CEST 2011

On 9 June 2011 01:25, Michael Scherer <misc at zarb.org> wrote:
+> 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
+>
+>
+
+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
+