From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20101008/001024.html | 97 +++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101008/001024.html (limited to 'zarb-ml/mageia-dev/20101008/001024.html') diff --git a/zarb-ml/mageia-dev/20101008/001024.html b/zarb-ml/mageia-dev/20101008/001024.html new file mode 100644 index 000000000..96faa590a --- /dev/null +++ b/zarb-ml/mageia-dev/20101008/001024.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Proposal: Updating released versions (long post) + + + + + + + + + +

[Mageia-dev] Proposal: Updating released versions (long post)

+ Luca Berra + bluca at vodka.it +
+ Fri Oct 8 09:36:09 CEST 2010 +

+
+ +
On Thu, Oct 07, 2010 at 07:49:29PM -0400, Frank Griffin wrote:
+>I'd like to propose the following model for updating released versions:
+>
+>1) Users should not have to see, except in minor ways, the different
+>repositories.  Urpmi may see them, and advanced or ideologically polar
+>users may care about them (e.g. free vs non-free), but most users
+I object to this specific point, if what we are doing is free software
+that should be made clear to users. and i believe the user shold be
+asked wether they want to use only free software or not.
+
+>2) The update tool we give these users should distinguish between
+>security updates and backports/testing, but present them both.  This is
+updates are not necessarily limited to security, but ok
+backports is one thing, testing is a completely different one
+the only use for testing is pulling out a specific (set of) packages for
+QA purpose, no user should ever see those.
+but the idea of separating the two in the user interface is sound.
+
+>(Here's the biggie :-) )
+>4) We need to enhance the urpmi.recover functionality and bring it fully
+>into mainstream urpmi so that ANY PACKAGE CAN BE ROLLED BACK TO ITS
+>PREVIOUS VERSION (sorry for the caps).  If we don't want to be stuck
+I just read it 3 times, and i still believe doing the above might prove to be a
+nightmare.
+rolling back a single, well identified change is a doable task.
+rolling back proceduraly a complex change becomes exponentially complex
+even for experienced system engineers, let alone a piece of software.
+
+i'll spend more time on doing qa on packages pushed to released distros.
+
+L.
+
+
+-- 
+Luca Berra -- bluca at vodka.it
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1