[Mageia-dev] Finalizing update process

Ahmad Samir ahmadsamir3891 at gmail.com
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


More information about the Mageia-dev mailing list