[Mageia-discuss] which version of a software in cauldron ?

Sun Oct 24 15:11:29 CEST 2010

I want to point a little problem about the version of a FOO software 
+included in the distribution :
+
+two ways for cauldron
+
+1 )  Use always the last  development release of FOO (beta or rc n+1)
+(means several downloadings of sources from the svn or git of the
+project, and several modifications of the spec file and patches)
+a) advantages for the packager : you are always able to build the rpm by
+adapting its spec file progressively, following the changes of the FOO
+software
+
+b) Problem for a tester of this FOO (n+1) software (I mean somebody
+wanting to contribute to the FOO project) :  if you use cauldron to test
+it, you may encounter bugs  and may not know if they belongs to cauldron
+or to the FOO (beta n+1) software
+
+c) Problem for the final user : when cauldron is frozen before the final
+release of Mageia, it may be frozen with a beta release of this software
+(n+1), still buggy ! and that's this buggy (beta or rc n+1) version
+which will be provided with the final release of Mageia.
+
+d) needs some acute attention from the packager : when a final release
+of the FOO (n+1)program appears and is packaged in cauldron : he MUST
+provide it in the updates repos of the last releases of Mageia (2011, 2012)
+
+
+2) Use only the last stable version of FOO (n) in cauldron :
+a) advantages for the packager : needs less frequent modifications of
+the spec files and uses of the buildsystem
+
+b) problem for the packager : needs a huge work in one time to adapt the
+spec file from (n) version to (n+1)
+
+c) Problem for the tester contributer of the FOO program : he can never
+test the betas or release candidates with rpms from Mageia
+
+d) advantages for the final user  : Mageia final release is always
+providing a stable release of the FOO software
+
+e) when a new stable version (n+1) of the FOO software appears, the
+packager may provide it to cauldron and to the updates repos of the last
+releases of Mageia (2011, 2012) in the same time BUT !!! these rpms
+haven't been tested as well as in first case (NB I'm not talking only of
+installing the packages but of the FOO program itself too, sometimes the
+FOO program needs some little adaptations for a particular distribution,
+and needs upstream feedback for this)
+
+
+
+
+A testing repo for the release of Mageia (2011, 2012) should be useful !
+but it can be understood in two different ways :
+
+1 ) It provides the rpm of the new stable release of FOO (n+1) 
+(published after the last version of Mageia 2012, and having yet been
+built for cauldron) to test if the rpm is OK before providing it as an
+update for Mageia (2011,2012) (eventually needing modifications of the
+spec file or needing upstream bug corrections to adapt the software for
+Mageia specificity)
+
+or
+2) It provides rpms of development versions (betas, rc) of FOO (n+1) to
+test and contribute to FOO project on a stable basis from Mageia before
+providing a rpm of the stable release of FOO (n+1) to updates repos and,
+in a second time only, the devs will adapt the spec files to Cauldron
+(the cauldron dev will not have to loose time with a buggy software !)
+
+
+To illustrate what I mean :
+
+An example with a software which has _always_ been _up to date in
+cooker _   following each beta or rc release,  but unfortunately badly
+affordable in Mandriva releases:
+
+Mandrake 10.2 *hugin** 0.5-0.beta4.1* (not easy to use) BAD
+Mandriva 2006 *hugin* *0.5-0.rc1* (freezes) BAD
+0.5 final release was never provided as update for Mandriva BAD
+Mandriva 2007.0 *hugin* *0.6.1* final release OK stable
+Mandriva 2007.1 *hugin* *0.6.1* final release OK stable
+Mandriva 2008.0 *hugin* *0.6.1* final release OK stable
+Mandriva 2008.1 *hugin* *0.7-0beta4.1* BAD
+Mandriva 2009.0 *hugin* *0.7.0-0rc6.1* BAD
+*hugin* *0.7.0*  final stable release was  never provided as update nor
+backport for Mandriva 2009.0 nor 2008.1 BAD
+nor provided for Mandriva 2009.1 BAD :
+Mandriva 2009.1 *hugin* *0.8.0-0.beta2.1* BAD
+*hugin 0.8* final release was never provided as update nor backport to
+2009.1 BAD
+Mandriva 2010.0 *hugin  2009.2.0*  (new version numbering) OK stable
+Mandriva 2010.1 *hugin* * 2009.4.0* _(quite_) OK stable
+*hugin* * 2010.0.0* published before Mandriva 2010.1 appears was not
+included in it nor provided as update nor backport for Mandriva
+*hugin 2010.2.0* published  10 october 2010 is in cooker ....
+
+*Please keep it and use it for Mageia*
+
+
+Sidetalk : I tried to compile hugin 0.7.0 or 0.8.0 final release for
+Mandriva 2008.1, it was not doable : from hugin 0.7.0 rc4 compiling
+hugin needed cmake : cmake(2.4.8) was buggy , not able to find the
+wxwidgets headers, and was never corrected nor updated for Mandriva
+2008.1...
+cmake had been updated for Mandriva 2009.0 but not backportable as it in
+Mandriva 2008.1...
+I had to use a srpm of cmake from fedora (2.6.2-3fc9) and could at least
+do it for myself
+
+For French readers it has already been discussed on Mandriva forum :
+http://forum.mandriva.com/viewtopic.php?t=114405&start=0&postdays=0&postorder=asc&highlight=hugin
+<http://forum.mandriva.com/viewtopic.php?t=114405&start=0&postdays=0&postorder=asc&highlight=hugin>
+
+
+Hope this will help to think about repo trees !
+Philippe
+
+
+
+
+
+ 
+