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

[Mageia-dev] Proposal of a backporting process

+ andre999 + andr55 at laposte.net +
+ Tue Jun 28 03:43:49 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+>
+> Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
+>> On 24 June 2011 02:09, Michael Scherer<misc at zarb.org>  wrote:
+
+...
+
+>>> - 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.
+>>
+>> Option 1 doesn't only mean not duplicating work, but also that the the
+>> spec in backports svn isn't ever out-dated; the only reason I see a
+>> package being in stable distro SVN is if it's in /release|updates, not
+>> backports...
+>
+> I'm not sure I understand your point. What do you mean with out-dated specs in
+> backports ?
+> I favor option 2 (with all needed useful shortcuts in mgarepo and BS to make
+> it simple for packagers) because it allows to cope with the following
+> situation :
+> - foo is in version 1.2.2 in release|updates
+> - foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for
+> the next stable release
+> - the latest release in the 1.x branch, 1.3.0, brings many features requested
+> by some users, we want to provide it as a backport : with option 1 we can't,
+> with option 2 we can.
+>
+> or :
+> - foo is in version 1.2.2 in release|updates
+> - foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for
+> the next stable release
+> - we had backported version 1.2.6 before switching to 2.0alpha in cauldron
+> - the backported version 1.2.6 has a big bug we hadn't spotted during tests
+> and we want to fix in the backport : with option 1 we can't, with option 2 we
+> can.
+>
+> So, for me, this is definitely option 2.
+
+Given this explanation, I would definitely go for option 2 as well.
+
+> However, I think it must be made a painless as possible to packagers :
+> - in the common case, allow to submit directly from cauldron to the backports
+> media, but let the BS detect that and automatically do the SVN copy part.
+> - for the situations I described above, work with the backport branch
+> similarly as we work on updates (technically speaking : SVN, BS...).
+
+Sound good to me.
+
+>>> 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.
+>>
+>> Probably off-topic, but how will that work with madb? i.e. how will
+>> the maintainer get the feedback?
+>
+> I partially answered above : either via bugzilla, or via a simple tracking
+> system included in madb for that need. It will depend on the chosen process,
+> we'll try to adapt the tool to the situation.
+
+I tend to like the idea of using bugzilla with a streamlined template, to avoid 
+unnecessary duplication of code to be maintained.
+But if madb can track things better, and it can be readily developed, that sounds good.
+As for packagers, it shouldn't make much difference if the tools are done right.
+
+> Best regards
+>
+> Samuel Verschelde
+
+Regards
+
+-- 
+André
+
+ + + +
+

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