diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005226.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005226.html | 170 |
1 files changed, 170 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005226.html b/zarb-ml/mageia-dev/2011-June/005226.html new file mode 100644 index 000000000..22cef1ed6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005226.html @@ -0,0 +1,170 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Finalizing update process + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Finalizing%20update%20process&In-Reply-To=%3CBANLkTi%3Dg2UfSOfGLgwbZnq7vNTCxmd9yrg%40mail.gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005225.html"> + <LINK REL="Next" HREF="005228.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Finalizing update process</H1> + <B>Ahmad Samir</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Finalizing%20update%20process&In-Reply-To=%3CBANLkTi%3Dg2UfSOfGLgwbZnq7vNTCxmd9yrg%40mail.gmail.com%3E" + TITLE="[Mageia-dev] Finalizing update process">ahmadsamir3891 at gmail.com + </A><BR> + <I>Thu Jun 9 01:40:15 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005225.html">[Mageia-dev] Finalizing update process +</A></li> + <LI>Next message: <A HREF="005228.html">[Mageia-dev] Finalizing update process +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5226">[ date ]</a> + <a href="thread.html#5226">[ thread ]</a> + <a href="subject.html#5226">[ subject ]</a> + <a href="author.html#5226">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On 9 June 2011 01:25, Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">misc at zarb.org</A>> wrote: +><i> Le jeudi 09 juin 2011 à 00:53 +0300, Ahmad Samir a écrit : +</I>>><i> On 8 June 2011 23:40, Anssi Hannula <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">anssi.hannula at iki.fi</A>> wrote: +</I>>><i> > On 08.06.2011 23:23, Ahmad Samir wrote: +</I>>><i> >> On 8 June 2011 21:45, Samuel Verschelde <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>> wrote: +</I>>><i> >>> Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : +</I>>><i> >>> +</I>>><i> >>>> IMHO, rejection reasons: +</I>>><i> >>> +</I>>><i> >>>> - The sec team doesn't think the update fixes a serious security +</I>>><i> >>> +</I>>><i> >>>> vulnerability; so it's not updates but backports +</I>>><i> >>> +</I>>><i> >>> What about bugfix updates ? I guess fixing a bug is a valid reason for an +</I>>><i> >>> update, like it was in Mandriva's updates. +</I>>><i> >>> +</I>>><i> >>> Regards +</I>>><i> >>> +</I>>><i> >>> Samuel +</I>>><i> >> +</I>>><i> >> Right, I probably phrased that one wrongly; I meant: +</I>>><i> >> fixes a serious bug, e.g. crashing, segfaulting +</I>>><i> > +</I>>><i> > I don't think we should exclude non-serious bugs :) +</I>>><i> > +</I>>><i> +</I>>><i> Depends, overworking the sec team doesn't look like a good aspect... +</I>>><i> (that's why I liked contrib in mdv, I could push an update any time, +</I>>><i> without having to go though the bug report -> QA -> Sec team loop). +</I>><i> +</I>><i> Well, I didn't asked to secteam to do anything except managing the +</I>><i> security aspect : +</I>><i> - finding CVE +</I>><i> - finding patch ( with the help of maintainer ) +</I>><i> - finding test and fixes +</I>><i> +</I>><i> But the building and updating should be done by maintainer, as this +</I>><i> would scale better. Let the security team focus on the security aspect, +</I>><i> and be there as a help for maintainers and viceversa. We shouldn't +</I>><i> overload the secteam, while maintainers are here for that :) +</I>><i> +</I>><i> One of the problem at Mandriva was that security and stable updates were +</I>><i> quite disconnected from maintainers, and so it didn't scale well. +</I>><i> +</I>><i> It didn't scale because people didn't know security procedure ( it was +</I>><i> not part of the expected curriculum of a packager, and often was done +</I>><i> without them implied ), it didn't scale because security was only for a +</I>><i> restricted set of salaree taking care of everything on separate +</I>><i> systems. +</I>><i> +</I>><i> I think we should focus on having : +</I>><i> - a system using already know procedure ( ie regular build system ) +</I>><i> - make sure that taking care of update is something done regulary as +</I>><i> part as packager duty ( after all, that's the whole part of being +</I>><i> maintainer ) +</I>><i> +</I>>><i> > (or version updates in some cases, like firefox/opera/flash or updating +</I>>><i> > an rc/beta version to a stable one, and maybe some online games that are +</I>>><i> > useless unless on latest version) +</I>>><i> > +</I>>><i> +</I>>><i> I agree, (except for the games part, nowadays if it's less than 4GB +</I>>><i> it's not really a "game"). +</I>><i> +</I>><i> I guess we can start with a list of exception : +</I>><i> +</I>><i> - stuff that should be updated to latest version, because the security +</I>><i> support for older releases ( firefox, chrome ) is too hard +</I>><i> -> we update to latest version if there is no regression and a strong +</I>><i> reason to upgrade ( severe bugfixes, security issue, breakages ). +</I>><i> Exception of this category should be very expectional +</I>><i> +</I>><i> - stuff where there is strict bugfixes only release +</I>><i> ( postgresql ), or update to a stable version ( which should be a bugfix +</I>><i> only release when compared to beta/rc :) ) +</I>><i> -> we upgrade to stable ( for rc/beta ) +</I>><i> -> we do version update if it is bug fixes and if the packager is ok +</I>><i> with it ( and if the rules of the bugfix branches are clearly documented +</I>><i> ) +</I>><i> +</I>><i> - everything else +</I>><i> -> only minimal patches +</I>><i> +</I>><i> The question of game is still open, ie, should it go in 1st category, or +</I>><i> should we have different rules to see what should be there or not ? +</I>><i> +</I>><i> I guess this would only be for networked game ? +</I>><i> +</I>>><i> Maybe the sec team should only work on sec fixes, and there should be +</I>>><i> a sub-group of the sec team that handle the not +</I>>><i> CVE|crash|segfaulting|buffer-overflow updates. +</I>><i> +</I>><i> segfault, crash are the duty of packager, as well as wrong requires or +</I>><i> anything. +</I>><i> -- +</I>><i> Michael Scherer +</I>><i> +</I>><i> +</I> +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 +</PRE> + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005225.html">[Mageia-dev] Finalizing update process +</A></li> + <LI>Next message: <A HREF="005228.html">[Mageia-dev] Finalizing update process +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5226">[ date ]</a> + <a href="thread.html#5226">[ thread ]</a> + <a href="subject.html#5226">[ subject ]</a> + <a href="author.html#5226">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |