diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101130/001555.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101130/001555.html | 117 |
1 files changed, 117 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101130/001555.html b/zarb-ml/mageia-dev/20101130/001555.html new file mode 100644 index 000000000..4b7bd48ab --- /dev/null +++ b/zarb-ml/mageia-dev/20101130/001555.html @@ -0,0 +1,117 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3CAANLkTik3v7hatsN1zYGVH0%3DOoHmhzb%3D0az%3DSU3MmcQU2%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="001548.html"> + <LINK REL="Next" HREF="001563.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Romain d'Alverny</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3CAANLkTik3v7hatsN1zYGVH0%3DOoHmhzb%3D0az%3DSU3MmcQU2%40mail.gmail.com%3E" + TITLE="[Mageia-dev] Mirror layout, round two">rdalverny at gmail.com + </A><BR> + <I>Tue Nov 30 14:48:55 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001548.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001563.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1555">[ date ]</a> + <a href="thread.html#1555">[ thread ]</a> + <a href="subject.html#1555">[ subject ]</a> + <a href="author.html#1555">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Tue, Nov 30, 2010 at 13:29, Samuel Verschelde <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>> wrote: +><i> What I'm saying is totally different : +</I>><i> +</I>><i> In the first case : +</I>><i> - no one steps in to maintain it. We drop it. +</I>><i> +</I>><i> In the second case : +</I>><i> - no one steps in to maintain it. Because we promised to support it, and because there are people who care about that (the QA Team Leader for example), we would *try very hard* to find a solution. this is a problem, we identify the problem, we try to solve it. Maybe we fail, but at least we try hard, because the package is on the "supported" list. +</I> +Ok, it's a degree of support management: + - first case, dropping is automatic, + - second case, we turn the red light on and try to organise around +this to find a "best effort" solution. + +But, in the second case, relying exclusively on the community, for the +support promise to work, you have to show that you have either some +separate incentive, either a large enough community to grow the +chances for this to happen. + +>><i> another solution : "we do no promises of supporting anything". +</I>><i> +</I>><i> This is a solution. Not mine however. +</I> +Not promising of something to happen is not a promise of this thing +not to happen. + +Such a promise of support is much more sustainable if you have a +clear, identifiable incentive or reason or experience (for the people +you promise to) to keep it. There are differences between: + * guaranteed, + * trying very hard, + * best effort, + * good will, + * nothing pretended + +support promises. + +><i> Let me present the idea differently. There are 2 levels of support : +</I>><i> +</I>><i> - top guaranteed support (a subset of packages) : those are packages your can rely on blindly, they'll be updated in a timely manner. Those are the packages the QA Team puts its limited resources on (doesn't mean the QA Team provides support, but they check that good support is provided). The maintainer is responsible for the package, but the QA Team is vigilant about them. +</I>><i> - supported packages (every other package) : those are maintained packages, however the QA Team doesn't have to check them. It's up to the maintainer. +</I>><i> - unsupported packages are dropped. +</I>><i> +</I>><i> So everything is supported, but there a special level of support for some critical components. +</I> +Just saying, but as packages support is to be distributed, we may as +well have commercial companies step around and manage this kind of +support: + * within/through Mageia through their employees (so, it matches our +policies, that's the idea), + * because it matches their activity/interest (they build the +software, they consult/sell/build around it). + +To help thinking about that (in the future, because now we have +nothing to track/compare) we need to collect and report relevant data +about packages management experience (supported, not supported, number +of updates, maintainers, time to push an update, etc.) against a first +policy. So we can measure what happens and what can be reasonably +changed/expected in the future. + +Romain +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001548.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001563.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1555">[ date ]</a> + <a href="thread.html#1555">[ thread ]</a> + <a href="subject.html#1555">[ subject ]</a> + <a href="author.html#1555">[ 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> |