summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/20101201/001568.html
diff options
context:
space:
mode:
Diffstat (limited to 'zarb-ml/mageia-dev/20101201/001568.html')
-rw-r--r--zarb-ml/mageia-dev/20101201/001568.html162
1 files changed, 162 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101201/001568.html b/zarb-ml/mageia-dev/20101201/001568.html
new file mode 100644
index 000000000..a47627e90
--- /dev/null
+++ b/zarb-ml/mageia-dev/20101201/001568.html
@@ -0,0 +1,162 @@
+<!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=%3CAANLkTi%3DNvoNwDLN4M1aMgUO9d9AstBNauV5boBZa6j43%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="001566.html">
+ <LINK REL="Next" HREF="001570.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Mageia-dev] Support policy</H1>
+ <B>Daniel Kreuter</B>
+ <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3CAANLkTi%3DNvoNwDLN4M1aMgUO9d9AstBNauV5boBZa6j43%40mail.gmail.com%3E"
+ TITLE="[Mageia-dev] Support policy">daniel.kreuter85 at googlemail.com
+ </A><BR>
+ <I>Wed Dec 1 09:42:18 CET 2010</I>
+ <P><UL>
+ <LI>Previous message: <A HREF="001566.html">[Mageia-dev] Support policy
+</A></li>
+ <LI>Next message: <A HREF="001570.html">[Mageia-dev] Support policy
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#1568">[ date ]</a>
+ <a href="thread.html#1568">[ thread ]</a>
+ <a href="subject.html#1568">[ subject ]</a>
+ <a href="author.html#1568">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>2010/12/1 Maarten Vanraes &lt;<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">maarten.vanraes at gmail.com</A>&gt;
+
+&gt;<i> Op dinsdag 30 november 2010 13:31:08 schreef Samuel Verschelde:
+</I>&gt;<i> &gt; Hi,
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; I would like to discuss the support policy for Mageia.
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; It would be interesting to know (or decide) where Mageia is heading,
+</I>&gt;<i> given
+</I>&gt;<i> &gt; our limited resources : 1) focus on stability and security : few very
+</I>&gt;<i> well
+</I>&gt;<i> &gt; equally supported packages. Apparently, this is where we're going for
+</I>&gt;<i> now.
+</I>&gt;<i> &gt; May be wise as a start, but I hope this is not our final destination,
+</I>&gt;<i> &gt; because it means either very limited choice, or progressive diminution of
+</I>&gt;<i> &gt; quality of support if the number of packages increases faster than the
+</I>&gt;<i> &gt; dedicated resources. 2) focus on choice : many packages, but no support
+</I>&gt;<i> &gt; policy. This would be really bad, I think we're not heading there, from
+</I>&gt;<i> &gt; what I read. However, this is a danger if we start from option 1) and
+</I>&gt;<i> then
+</I>&gt;<i> &gt; open wide the gates for importing packages, without setting a support
+</I>&gt;<i> &gt; policy. 3) focus on both (this is my option). There would be 2 levels of
+</I>&gt;<i> &gt; support : - top guaranteed support : those are the (few at start)
+</I>&gt;<i> packages
+</I>&gt;<i> &gt; your can rely on almost blindly, they'll be updated in a timely manner,
+</I>&gt;<i> &gt; and updates don't break things. Those are the packages the QA Team puts
+</I>&gt;<i> &gt; its limited resources on (doesn't mean the QA Team provides the support
+</I>&gt;<i> &gt; themselves, this is maintainer work, but they check that good support is
+</I>&gt;<i> &gt; provided) : testing, helping the maintainers to watch for security
+</I>&gt;<i> &gt; problems... The maintainers are responsible for their package, but the QA
+</I>&gt;<i> &gt; Team double-checks updates for stable releases. - supported packages
+</I>&gt;<i> &gt; (every other package) : those are maintained packages, however the QA
+</I>&gt;<i> Team
+</I>&gt;<i> &gt; doesn't have to check them. It's up to the maintainer to check the
+</I>&gt;<i> package
+</I>&gt;<i> &gt; and updates quality. - unsupported packages are dropped.
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; Are we heading for 1), 2), 3), or any other option ?
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; Of course, with unlimited resources, options 1 and 3 would be equivalent,
+</I>&gt;<i> &gt; everything would have the &quot;top guaranteed support&quot; :)
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; Best regards
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; Samuel Verschelde
+</I>&gt;<i> &gt; Packager/QA Team/User
+</I>&gt;<i>
+</I>&gt;<i>
+</I>&gt;<i> having read misc's lenghty and almost political proposal, i suggest a 4th
+</I>&gt;<i> option (even though i'm not part of QAteam either):
+</I>&gt;<i>
+</I>&gt;<i> 4) dynamically distributed focus:
+</I>&gt;<i> - level 1: BuildSystem-required packages (all packages used for buildnodes)
+</I>&gt;<i> - level 2: everything that is minimally required to boot and do stuff
+</I>&gt;<i> - level 3: popular server packages
+</I>&gt;<i> - level 4: release focus (everything that's defaultly installed by a
+</I>&gt;<i> release)
+</I>&gt;<i> - level 4b: stage images
+</I>&gt;<i> - level 5: the rest
+</I>&gt;<i>
+</I>&gt;<i> depending on resources and certain timings; focus should be spread
+</I>&gt;<i> according
+</I>&gt;<i> to desires at that time.
+</I>&gt;<i>
+</I>&gt;<i> eg:
+</I>&gt;<i> - i imagine that level 1 could be discussed between sysadm and qateam
+</I>&gt;<i> during
+</I>&gt;<i> BS-updates
+</I>&gt;<i> - i imagine that level 2 would be the primary focus
+</I>&gt;<i> - i imagine that level 4 could be more important during release times
+</I>&gt;<i> - i imagine that level 5 would probably not be focussed by QA unless
+</I>&gt;<i> unlimited
+</I>&gt;<i> resources
+</I>&gt;<i> - i imagine that level 3 would probably be good if resources would be
+</I>&gt;<i> growing,
+</I>&gt;<i> and possibly level 4 if there's enough resources.
+</I>&gt;<i>
+</I>&gt;<i>
+</I>&gt;<i> - i agree that testing should be open to anyone
+</I>&gt;<i> - i agree that karma could not be a bad idea, but suggest that QAteam give
+</I>&gt;<i> more karma (perhaps even on the karmic state of that person)
+</I>&gt;<i> - i also would suggest that at the time of alpha release, we should do a
+</I>&gt;<i> contest on testing and bugfinding; so that we could gather enough testers;
+</I>&gt;<i> and
+</I>&gt;<i> possibly even extra packagers or qateam people.
+</I>&gt;<i>
+</I>&gt;<i> WDYT?
+</I>&gt;<i>
+</I>
+
+Option 4 sounds good, it also shows a little bit the responsibilities of
+each team.
+I would like to add a level 3b which differs between server-only and
+desktop.
+
+
+--
+Mit freundlichen Gr&#252;&#223;en
+
+Greetings
+
+Daniel Kreuter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: &lt;/pipermail/mageia-dev/attachments/20101201/1604e755/attachment-0001.html&gt;
+</PRE>
+
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI>Previous message: <A HREF="001566.html">[Mageia-dev] Support policy
+</A></li>
+ <LI>Next message: <A HREF="001570.html">[Mageia-dev] Support policy
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#1568">[ date ]</a>
+ <a href="thread.html#1568">[ thread ]</a>
+ <a href="subject.html#1568">[ subject ]</a>
+ <a href="author.html#1568">[ 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>