diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101201/001566.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101201/001566.html | 130 |
1 files changed, 130 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101201/001566.html b/zarb-ml/mageia-dev/20101201/001566.html new file mode 100644 index 000000000..e3db63425 --- /dev/null +++ b/zarb-ml/mageia-dev/20101201/001566.html @@ -0,0 +1,130 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Support policy + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3C201012010033.32924.maarten.vanraes%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001574.html"> + <LINK REL="Next" HREF="001568.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Support policy</H1> + <B>Maarten Vanraes</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3C201012010033.32924.maarten.vanraes%40gmail.com%3E" + TITLE="[Mageia-dev] Support policy">maarten.vanraes at gmail.com + </A><BR> + <I>Wed Dec 1 00:33:32 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001574.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001568.html">[Mageia-dev] Support policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1566">[ date ]</a> + <a href="thread.html#1566">[ thread ]</a> + <a href="subject.html#1566">[ subject ]</a> + <a href="author.html#1566">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op dinsdag 30 november 2010 13:31:08 schreef Samuel Verschelde: +><i> Hi, +</I>><i> +</I>><i> I would like to discuss the support policy for Mageia. +</I>><i> +</I>><i> It would be interesting to know (or decide) where Mageia is heading, given +</I>><i> our limited resources : 1) focus on stability and security : few very well +</I>><i> equally supported packages. Apparently, this is where we're going for now. +</I>><i> May be wise as a start, but I hope this is not our final destination, +</I>><i> because it means either very limited choice, or progressive diminution of +</I>><i> quality of support if the number of packages increases faster than the +</I>><i> dedicated resources. 2) focus on choice : many packages, but no support +</I>><i> policy. This would be really bad, I think we're not heading there, from +</I>><i> what I read. However, this is a danger if we start from option 1) and then +</I>><i> open wide the gates for importing packages, without setting a support +</I>><i> policy. 3) focus on both (this is my option). There would be 2 levels of +</I>><i> support : - top guaranteed support : those are the (few at start) packages +</I>><i> your can rely on almost blindly, they'll be updated in a timely manner, +</I>><i> and updates don't break things. Those are the packages the QA Team puts +</I>><i> its limited resources on (doesn't mean the QA Team provides the support +</I>><i> themselves, this is maintainer work, but they check that good support is +</I>><i> provided) : testing, helping the maintainers to watch for security +</I>><i> problems... The maintainers are responsible for their package, but the QA +</I>><i> Team double-checks updates for stable releases. - supported packages +</I>><i> (every other package) : those are maintained packages, however the QA Team +</I>><i> doesn't have to check them. It's up to the maintainer to check the package +</I>><i> and updates quality. - unsupported packages are dropped. +</I>><i> +</I>><i> Are we heading for 1), 2), 3), or any other option ? +</I>><i> +</I>><i> Of course, with unlimited resources, options 1 and 3 would be equivalent, +</I>><i> everything would have the "top guaranteed support" :) +</I>><i> +</I>><i> Best regards +</I>><i> +</I>><i> Samuel Verschelde +</I>><i> Packager/QA Team/User +</I> + +having read misc's lenghty and almost political proposal, i suggest a 4th +option (even though i'm not part of QAteam either): + +4) dynamically distributed focus: +- level 1: BuildSystem-required packages (all packages used for buildnodes) +- level 2: everything that is minimally required to boot and do stuff +- level 3: popular server packages +- level 4: release focus (everything that's defaultly installed by a release) +- level 4b: stage images +- level 5: the rest + +depending on resources and certain timings; focus should be spread according +to desires at that time. + +eg: +- i imagine that level 1 could be discussed between sysadm and qateam during +BS-updates +- i imagine that level 2 would be the primary focus +- i imagine that level 4 could be more important during release times +- i imagine that level 5 would probably not be focussed by QA unless unlimited +resources +- i imagine that level 3 would probably be good if resources would be growing, +and possibly level 4 if there's enough resources. + + +- i agree that testing should be open to anyone +- i agree that karma could not be a bad idea, but suggest that QAteam give +more karma (perhaps even on the karmic state of that person) +- i also would suggest that at the time of alpha release, we should do a +contest on testing and bugfinding; so that we could gather enough testers; and +possibly even extra packagers or qateam people. + +WDYT? +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001574.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001568.html">[Mageia-dev] Support policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1566">[ date ]</a> + <a href="thread.html#1566">[ thread ]</a> + <a href="subject.html#1566">[ subject ]</a> + <a href="author.html#1566">[ 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> |