Lucid Arm Kernels

[Tim Gardner]

Andy Whitcroft wrote:
> The purpose of this email is to start to document and discuss the plan
> for the existing ARM branches (imx-51 and mvl-dove) for the Lucid cycle.
> It will also describe the implementation of this plan in particular
> indicating where we have to deviate from that plan due to external
> constraints.
> 
> The Problem: Last cycle it took a very very long time to get working
> kernels for the ARM boards and this reduced the time available for the
> mobile teams to complete the userspace porting for these platforms.
> Generally pushing us late into the cycle and up against the freezes.
> 
> The Logical Plan: The plan is to keep the ARM branches back on the
> Karmic kernels until such time as a stable kernel replacement is ready
> for those platforms.  We would maintain the kernels in Karmic as normal
> and copy those kernels forward to Lucid as they are updated.  When and if
> a replacement kernel is available for a platform we would then break the
> link between Karmic and Lucid and update Lucid only to the updated version.
> We do not envision the ARM kernel would be newer than the distro kernel.
> 
> Issues: There are a number of issues which lead us to not be able to use
> the exact same kernel source and binaries for both Karmic and Lucid
> going forward:
> 
> 1) the archive does not allow a package to have the same filename in two
>    releases beyond the initial copy from Karmic to Lucid,
> 2) the compiler in Lucid is likely to be updated to a newer version than
>    that in Karmic and we desire the kernel to be compiled with the same
>    compiler as installed on the system, and
> 3) the archive is being rebuilt for Lucid using arm-v7 as a base and
>    we desire the kernel to be compiled correctly (does this affect the
>    kernel?).
> 
> The first of these throws up additional issues, particularly in combination
> with 2 & 3.  If the kernel version cannot be the same in the two series
> then we have to maintain separate version numbers in each.  Talking this
> through with the archive admins there is one simple requirement, the
> version numbers must not match in the two series and must be higher in
> the later series to make upgrades work as expected.
> 
> Option ~karmic1: The common way to deal with this is to upload the updated
> package to Lucid (the newer series) and then update the changelog leader
> as below and re-upload for Karmic (the older series); indeed SRU policy
> tends to encourage this through an implied requirement that a fix is
> in Development before being SRUd.  So we would build a source package
> as normal, then modify the changelog as below and rebuild the source
> package again:
> 
>     linux-mvl-dove (2.6.31-208.17) lucid; urgency=low
>     [...]
> 
> becomes:
>     linux-mvl-dove (2.6.31-208.17~karmic1) karmic-proposed; urgency=low
>     [...]
> 
> So we can build the very same source tree into two very similar source
> tarballs and upload them both in a scriptable manner.  We would likely have
> the branches in only one of the repositories (perhaps Karmic as if we get
> an updated version for Lucid we would want to put that only in Lucid).
> We would then work on the branch as normal, but build and upload two
> source packages as above.
> 
> Now this works pretty nicely until and if we have to diverge the two trees.
> If the new Lucid version is a different base kernel version (say 2.6.32)
> then we have no issue we simply start the new branch in Lucid and we are
> good.  However if we got a complete rewrite of one of the ARM patchsets
> at the same base version, then we would have to work to split the version
> numbers as the ABIs could no longer be in lockstep.  The obvious solution
> there is to simply jump the Lucid ABI number to an unused range (say 600)
> and continue from there.  The main issue here is knowing where to find a
> lucid kernel source for arm, and knowing where you should be uploading to.
> 
> Option lucid1: We should also be able to do the inverse working in karmic
> and postfixing for Lucid, still uploading Lucid first:
> 
>     linux-mvl-dove (2.6.31-208.17) karmic-proposed; urgency=low
>     [...]
> 
> becomes:
>     linux-mvl-dove (2.6.31-208.17lucid1) lucid; urgency=low
>     [...]
> 
> This would have the advantage that the branch would be in the repository
> which the version first appeared, it would also be configured to upload
> to that repository.  The same caveats would apply in the face of a
> divergance as do for the ~karmic1 option.
> 
> Option split ABI: We could alternatively start from day one by splitting
> the ABI and handling both trees in lock step but as concurrent branches.
> Applying changes to Lucid, uploading there, then cherry-picking those
> back into the Karmic repo and uploading there as well.  Here we would
> move to the split ABI mode immediatly.
> 
>     linux-mvl-dove (2.6.31-600.1) lucid; urgency=low
>     [...]
> 
> and: 
>     linux-mvl-dove (2.6.31-208.17) karmic-proposed; urgency=low
>     [...]
> 
> Each of these options has issues.  In the ~karmic1 option we have more
> trouble finding the kernel source for a specific branch likely you
> would find the Lucid branches in the Karmic tree, but configured for
> Lucid upload.  In the lucid1 option you would at least find the tree
> in the git tree for the series in which it is based, and configured for
> that release.  However in both of these the changelog is necessarly wrong
> in the postfixed versions for all but the very last changelog.  The split
> ABI option would allow divergence but require greater effort maintaining
> the two trees before they diverge as we would maintain both trees manually.
> 
> I feel that the ~karmic1 version is probabally the most correct as the
> development release changelog is more pure going forward.  But that is a
> little more complex to understand as the Lucid main branch would be in
> the Karmic tree.  The lucid1 option most directly matches our desired
> functionality, but produces a less pure changelog in development.
> 
> I am tending to the lucid1 option at this time as it keeps the less
> obvious handling in Lucid for now and we can upgrade to split ABI at any
> time should we find it is not working.
> 
> Thoughts?
> 
> -apw
> 

In my opinion the only way to do this is 'Option split ABI' and carry 
Lucid fsl-imx51 and mvl-dove branches in the Karmic repo. I realize the 
naming is a bit unorthogonal, but its also possible that one or more of 
the ARM flavours will eventually migrate to newer kernel versions during 
the Lucid cycle. If that happens, then we'll start new branches in the 
Lucid repo.

rtg
-- 
Tim Gardner tim.gardner at canonical.com