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/2011-June/005976.html | 126 +++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005976.html (limited to 'zarb-ml/mageia-dev/2011-June/005976.html') diff --git a/zarb-ml/mageia-dev/2011-June/005976.html b/zarb-ml/mageia-dev/2011-June/005976.html new file mode 100644 index 000000000..932e3c0c3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005976.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Proposal of a backporting process + + + + + + + + + +

[Mageia-dev] Proposal of a backporting process

+ Michael Scherer + misc at zarb.org +
+ Fri Jun 24 02:09:55 CEST 2011 +

+
+ +
Hi,
+
+as said in the thread of firefox 5, and in the meeting of packager
+sooner this week, this is the first mail about backports ( on 3 ).
+
+So here is the proposal of a process, based on the feedback of people,
+and the idea of some packagers ( mainly stormi ).
+
+
+- Someone request a backport ( by bugzilla, by madb, by a email, by
+taking a packager family in hostage, whatever ). I would prefer use
+bugzilla but this may not be very user friendly, or too heavy.
+
+- a packager decide to do it. Based on the policy ( outlined in another
+mail ), and maybe seeing with the maintainer first about that for non
+trivial applications, the backport can be done, or not. The criterias
+for being backported or not are not important to the process, just
+assume that they exist for now ( and look at next mail ). So based on
+criteria, someone say "it can be backported, so I do it".
+
+- I am not sure on this part, but basically, we have 2 choices :
+  - the packager take the cauldron package and push to backport testing
+  - the packager move the cauldron package in svn to backport, and there
+send it to backport testing. 
+
+Proposal 1 mean less work duplication, but proposal 2 let us do more
+customization.
+
+if the package doesn't build, the packager fix ( or drop the idea if
+this requires too much work )
+
+- the packager send requesting feedback about the backport from the
+people who requested it, and test it as well.
+ 
+- based on feedback ( ie if the package work or if the packager is
+confident ), the packager decide to move it to backport for everybody,
+using some stuff similar to rpmctl ( the tool we used to move package at
+Mandriva ). The tool would also send notifications.
+
+- if the package doesn't work, he either fix, or drop the backport idea.
+If he fix, we go back on testing, if he drop, we remove the rpm ( with a
+automated cleaning of rpm after 1 or 2 months ).
+
+If the packager drop the backport, it should be notified to the
+requester ( hence the use of bugzilla, or a more suitable tool )
+
+This way :
+- packages are not sent untested, thus raising confidence in backports
+- the QA should not be overloaded, and can focus on updates
+- sysadmins are not overloaded 
+- people requesting backport see how QA work, and are involved into the
+distribution as testers, thus creating a much healthier discussion with
+packagers, and creating more incentive to help. And since they request
+the package, they will be motivated to test more than stuff they do not
+use.
+
+WDYT ?
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + +
+

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