diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101202/001579.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101202/001579.html | 167 |
1 files changed, 167 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101202/001579.html b/zarb-ml/mageia-dev/20101202/001579.html new file mode 100644 index 000000000..4aee1708e --- /dev/null +++ b/zarb-ml/mageia-dev/20101202/001579.html @@ -0,0 +1,167 @@ +<!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=%3C4CF7916B.6060504%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001578.html"> + <LINK REL="Next" HREF="001580.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Support policy</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3C4CF7916B.6060504%40laposte.net%3E" + TITLE="[Mageia-dev] Support policy">andr55 at laposte.net + </A><BR> + <I>Thu Dec 2 13:30:35 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001578.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001580.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1579">[ date ]</a> + <a href="thread.html#1579">[ thread ]</a> + <a href="subject.html#1579">[ subject ]</a> + <a href="author.html#1579">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Maarten Vanraes a écrit : +><i> +</I>><i> Op dinsdag 30 november 2010 13:31:08 schreef Samuel Verschelde: +</I>>><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 : +</I>>><i> 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. +</I>>><i> 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. +</I>>><i> 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>Hopefully for (3) +>><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>><i> +</I>><i> +</I>><i> having read misc's lenghty and almost political proposal, i suggest a 4th +</I>><i> option (even though i'm not part of QAteam either): +</I>><i> +</I>><i> 4) dynamically distributed focus: +</I>><i> - level 1: BuildSystem-required packages (all packages used for buildnodes) +</I>><i> - level 2: everything that is minimally required to boot and do stuff +</I>><i> - level 3: popular server packages +</I>><i> - level 4: release focus (everything that's defaultly installed by a release) +</I>><i> - level 4b: stage images +</I>><i> - level 5: the rest +</I>><i> +</I>><i> depending on resources and certain timings; focus should be spread according +</I>><i> to desires at that time. +</I>><i> +</I>><i> eg: +</I>><i> - i imagine that level 1 could be discussed between sysadm and qateam during +</I>><i> BS-updates +</I>><i> - i imagine that level 2 would be the primary focus +</I>><i> - i imagine that level 4 could be more important during release times +</I>><i> - i imagine that level 5 would probably not be focussed by QA unless unlimited +</I>><i> resources +</I>><i> - i imagine that level 3 would probably be good if resources would be growing, +</I>><i> and possibly level 4 if there's enough resources. +</I>><i> +</I>><i> +</I>><i> - i agree that testing should be open to anyone +</I>><i> - i agree that karma could not be a bad idea, but suggest that QAteam give +</I>><i> more karma (perhaps even on the karmic state of that person) +</I>><i> - i also would suggest that at the time of alpha release, we should do a +</I>><i> contest on testing and bugfinding; so that we could gather enough testers; and +</I>><i> possibly even extra packagers or qateam people. +</I>><i> +</I>><i> WDYT? +</I>I like your "karma" :) +><i> +</I>><i> +</I>Basicly, I see your option (4) as an elaboration of what I would expect +to be the supported part of Samuel's option (3) +Which accords nicely with my view. + +My idea of core packages - to be formally supported as suggested in (3) +- would be those typically needed in a desktop or server or development +system, adding LibreOffice (OpenOffice) and Firefox as useful widely +used applications. +Exactly what we support initially could start smaller, but that would be +my goal. + +And what is to be specifically supported should be decided by concensus. +Note that I would prefer that core be relatively restricted, compared +with "main" - and eventually, as resources increase, informal QA support +could be extended beyond core, for more critical bugs, for example. +Which is probably part of my preference for using "core" (officially +supported) and "extra" (others) groups of repositories for the mirrors. + +I'd like to see our first release (in April ?) be a fully usable system, +and not just a precursor to a distro that might eventually arrive. +Which means that we will need a lot of auxiliary packages, not all of +which would be as fully tested as core packages should be. +In other words, option (1) would not meet this goal. + +It seems a good idea to have only actively supported packages on the +first release. + +regards + +- André +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001578.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001580.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1579">[ date ]</a> + <a href="thread.html#1579">[ thread ]</a> + <a href="subject.html#1579">[ subject ]</a> + <a href="author.html#1579">[ 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> |