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/005322.html | 216 +++++++++++++++++++++++++++++++ 1 file changed, 216 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005322.html (limited to 'zarb-ml/mageia-dev/2011-June/005322.html') diff --git a/zarb-ml/mageia-dev/2011-June/005322.html b/zarb-ml/mageia-dev/2011-June/005322.html new file mode 100644 index 000000000..2bc7ea0ce --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005322.html @@ -0,0 +1,216 @@ + + + + [Mageia-dev] Missing packages in Mageia 1. How to backport? + + + + + + + + + +

[Mageia-dev] Missing packages in Mageia 1. How to backport?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Jun 10 10:56:35 CEST 2011 +

+
+ +
'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble:
+> On 9 June 2011 14:22, Oliver Burger <oliver.bgr at googlemail.com> wrote:
+>> Dexter Morgan <dmorganec at gmail.com> schrieb am 09.06.2011
+>>
+>>> On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie <mageia at colin.guthr.ie>
+>>> wrote:
+>>
+>>>> I think updates would be the right place.
+>>
+>>>
+>>
+>>> Please no 3rd repo :)
+>>
+>>> But i agree with you for updates for "new" packages ( no "new"
+>>
+>>> versions ;) )
+>>
+>>
+>> I would prefer using updates over backports as well. If we use backports we
+>> would get more problems then benefit (like people not having backports
+>> enabled or people having backports enabled and thus getting problems they
+>> can't handle e.g. with new kernels, graphic drivers and so on).
+>>
+>>
+>> Perhaps we could upload them to updates/testing for a really short qa before
+>> moving them to updates/ ?
+>>
+>>
+>> Oliver
+> 
+> If it's pushed to /updates then it should be imported to the stable
+> release SVN tree; note that at some point Cauldron could get a newer
+> version than the one in /updates, and maybe it's not backportable, new
+> deps, regressions... etc. But now if there's a bug in the version in
+> the stable */updates, and it needs a patch, what are you gonna base
+> the patch on if you submit directly from the Cauldron SVN checkout to
+> */updates, and the Cauldron package has already changed?
+> 
+> But if new package can go directly to updates.. that doesn't look
+> right to me, because at which point will "new" packages stop going to
+> a stable release */updates? if it goes on and on, then we're talking
+> about a semi-cauldron-like repo.
+
+So just svn cp it to the /1/updates tree in svn and job's a good 'un.
+(well svn cp is no longer just one step due to source separation, but
+the principle is the same!).
+
+
+> Also note that a new package in Cauldron gets tested for a while
+> (depending at which point it was imported during the release cycle),
+> but if gets pushed to /updates and not backports (which is "not
+> supported"), that testing period is short-circuited.
+
+Yeah but then the examples I've got so far are:
+
+ * trac
+ * supybot
+ * supybot-Meetbot
+ * passwd-gen
+ * dd_rescue
+
+In all these cases, these are packages I use. I will be testing them on
+that version of the distro. And when I don't use them every day, (e.g.
+passwd-gen, dd_rescue), they are pretty standard, stable and standalone
+apps.
+
+IMO we can over-analyse the "risk" factor here massive to the detriment
+of the overall offering.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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