diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101008/001034.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101008/001034.html | 119 |
1 files changed, 119 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101008/001034.html b/zarb-ml/mageia-dev/20101008/001034.html new file mode 100644 index 000000000..7a87955dd --- /dev/null +++ b/zarb-ml/mageia-dev/20101008/001034.html @@ -0,0 +1,119 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] How will be the realese cycle? + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20How%20will%20be%20the%20realese%20cycle%3F&In-Reply-To=%3C201010081816.29518.bgmilne%40multilinks.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001031.html"> + <LINK REL="Next" HREF="001035.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] How will be the realese cycle?</H1> + <B>Buchan Milne</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20How%20will%20be%20the%20realese%20cycle%3F&In-Reply-To=%3C201010081816.29518.bgmilne%40multilinks.com%3E" + TITLE="[Mageia-dev] How will be the realese cycle?">bgmilne at multilinks.com + </A><BR> + <I>Fri Oct 8 19:16:29 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001031.html">[Mageia-dev] How will be the realese cycle? +</A></li> + <LI>Next message: <A HREF="001035.html">[Mageia-dev] [Mageia] Will Mageia offer MeeGo ? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1034">[ date ]</a> + <a href="thread.html#1034">[ thread ]</a> + <a href="subject.html#1034">[ subject ]</a> + <a href="author.html#1034">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Friday, 8 October 2010 16:30:42 andré wrote: +><i> Michael Scherer a écrit : +</I>><i> > Le jeudi 07 octobre 2010 à 11:14 -0400, Greg Harris a écrit : +</I>><i> >> I certainly agree, and mean no disrespect to you and other maintainers +</I>><i> >> who generously contribute their time and energy. But the Mandriva +</I>><i> >> implementation of backports is not a solution for those who want a +</I>><i> >> continuously updated distro. It works for me and I appreciate that it's +</I>><i> >> there. But if you are going to design a new and appealing alternative, +</I>><i> >> the effort required to make backports really known and useful needs to +</I>><i> >> be taken into account. +</I>><i> > +</I>><i> > Well, that's a long running task. First, we have added meta data to +</I>><i> > repository so we could design a better interface for the software ( ie, +</I>><i> > how to detect that a packages is a backport and how to see a software is +</I>><i> > a update, a test update, or something else ), then we need to implement +</I>><i> > the soft, etc. +</I>><i> > +</I>><i> > You spoke of having backport by default. We used to do it, but too much +</I>><i> > people faced issue and complained. So we 1) said the truth, aka backport +</I>><i> > didn't have the same rigorous testing 2) disabled it by default. +</I>><i> > +</I>><i> > Now, if things change ( ie, if we have a process with more QA ), we can +</I>><i> > change again. +</I>><i> +</I>><i> Backports are definitely an area needing improvement. Firstly, it is a +</I>><i> bit awkward - especially with the waiting for Rpmdrake to process - to +</I>><i> temporarily access backports. +</I> +I thought you could just select the backports dropdown? If not, maybe you +should rather use 'urpmi --searchmedia Backports <packagename>'. + +Anyway, this isn't an issue with the "release cycle" aspect, it is a UI/design +problem in rpmdrake. + +><i> And when I have, most of the time what I was interested in was not as up +</I>><i> to date as the developper's site, if there was a backport for the +</I>><i> application (or type of application) in question. +</I> +Was it up-to-date in cooker? If not, this is probably purely a man-power +problem. If it was, did you request a backport? As I mentioned before, I think +one shortcoming of backports was knowing what packages people were interested +in having backported. + +But, I know of many instances where backports were requested on IRC, and +provided within under an hour (on the fast mirrors). + +><i> Luckily, being a programmer, it is not problematic for me to compile and +</I>><i> create menu entries, etc, if necessary. +</I> +There's no reason you should waste time that could be better spent. In some +cases, pushing a backport takes all of 2 minutes. + +</PRE> + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001031.html">[Mageia-dev] How will be the realese cycle? +</A></li> + <LI>Next message: <A HREF="001035.html">[Mageia-dev] [Mageia] Will Mageia offer MeeGo ? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1034">[ date ]</a> + <a href="thread.html#1034">[ thread ]</a> + <a href="subject.html#1034">[ subject ]</a> + <a href="author.html#1034">[ 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> |