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

[Thomas Backlund]

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