[Mageia-dev] Finalizing update process

[Michael Scherer]

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