[Mageia-dev] RFC: Opening Backports (once again...)

Wed Dec 7 20:06:04 CET 2011

Anssi Hannula skrev 6.12.2011 01:29:
+> On 06.12.2011 00:56, Thomas Backlund wrote:
+>>
+>> Now,
+>>
+>> here comes the question about backports once again.
+>>
+>> We are now 6+ months into Mageia 1, and we are nowhere closer to opening
+>> backports that we were at Mageia 1 release time.
+>>
+>> Because of that there are 3rdparty repos popping up everywhere...,
+>> something we hoped to avoid atleast partly when starting this project.
+>>
+>> And at current rate we will probably release Mageia "infinity"
+>> before backports is opened.
+>>
+>>
+>> It has been delayed because of needed infrastructure changes,
+>> something no-one have had time to do so far...
+>>
+>> I know there is "only some coding missing" and "someone should
+>> do it", buth truthfully there are only a few that knows the
+>> code used in the buildsystem enough to actually make it happend,
+>> and they are already othervise busy or overloaded...
+>> (this is no rant against them, as all here are using their
+>>   personal free time to help out)
+>
+> The biggest problem for me is that it is really difficult to test any
+> changes, one'd need a mockup of the whole buildsystem... and I don't
+> want to propose any patches blind :)
+>
+>> And to be honest I dont see that changing anytime soon...
+>>
+>>
+>> So here is a suggestion to get some value to our endusers:
+>>
+>> we add a backports branch on svn
+>>
+>> So packages for backports would use:
+>>
+>> svn.mageia.org/packages/backports/1/<package>/{current,pristine,releases}
+>>
+>> and allow that to be used for backports.
+>>
+>> Using a separate branch is also a cleaner way of providing
+>> backports, and makes it easy to separate changes needed only
+>> for Cauldron (or backports).
+>
+> Hm, how does this help with enabling backports (i.e. compared to simply
+> using cauldron repo)?
+>
+
+It was suggested to prevent direct submissions from cauldron as
+current BS is not capable of blocking cauldron -> updates_testing
+if we add cauldron to supported url
+
+So a separate backports branch would be created to "work around" this.
+(yes I know you could do svn cp and then submit, but atleast it would
+  prevent submissions done by mistake)
+
+And if we want to extend the checks, maybe mgarepo could be updated to
+only allow submission to backports_testing from backports branch until
+server side checking is in place. (the same "connection" could probably
+be done between updates_testing and updates too)
+
+
+> Anyway, would the above branch work like this:
+>
+> e.g. lets imagine I want to, in order:
+> 1. provide foobar 1.1 to backports.
+> 2. cauldron foobar upgraded to 1.2, some patches added, some removed,
+>     and other changes
+> 3. provide foobar 1.2 to backports
+> 4. 1.3 to cauldron and backports
+>
+> To backport foobar 1.1, I guess I'd simply do
+>    svn copy svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar \
+>             svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
+> and then the submit command.
+>
+> When time comes to provide foobar 1.2 to backports, the options are:
+> Option 1:
+>    svn del svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
+>    svn copy svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar \
+>             svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
+>    and submit. Changelog is the same as in cauldron.
+>
+> Option 2:
+>    svn checkout \
+>      svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar/current \
+>      foobar
+>    cd foobar&&  svn merge -r prevrev:HEAD \
+> 	svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar/current
+>    svn commit
+>    # copy all the log entries from the cauldron interval to the log msg
+>    and submit.
+>    Note: results in broken changelogs unless one does manual
+>    markreleases, but changelogs are already broken both in mga1 updates
+>    and in cauldron (youri issue [1]). This is more notable here, though,
+>    as backports happen generally more often multiple times than updates.
+>
+> Repeat with 1.3.
+>
+> Correct?
+>
+
+I guess this is up to the maintainer how he/she wants to maintain the
+backports of his package as it can also be Option 3: maintain backports
+branch separately (depending on package).
+
+For example, for me I'd like to provide kernel-rt-3.0.x as backports,
+but would probably not provide 3.2.x at all for Mageia 1.
+
+(sidenote, kernel-rt is a little tricky here as it was available as
+   2.6.33 series in 2010.2, so it could go to updates. but since it
+   would also need  backported nvidia/fglrx (if they work that is),
+   and the /proc/net/route info changed in 2.6.39 so it would "break"
+   network detection too, and version 3.* could break some scripts
+   checking for 2.*, so I'd rather submit it as a backport.)
+
+> [1] https://bugs.mageia.org/show_bug.cgi?id=2633
+>
+
+Yeah, this is another thing that needs to be fixed regardless of
+what we do with backports. for now we have just disabled markrel
+for updates so it does not mess up the changelogs even more.
+
+--
+Thomas
+