Stable derivative branch handling

Stefan Bader stefan.bader at canonical.com
Tue Jun 14 11:48:42 UTC 2011


On 14.06.2011 13:10, David Henningsson wrote:
> On 2011-06-13 15:46, Andy Whitcroft wrote:
>> After some discussion on IRC it was decided that it is time we formalised
>> the process for derivative branches and the interactions between the core
>> team and the domain experts for preparing kernels for release, such that we
>> have formal checkpoints in the stable cadance to ensure that the derivative
>> branches are updated when required but do not prevent forward progress.
>>
>> To this end once the main distro kernel tree are prepared the kernel
>> stable team will announce their availability to the derivative branch
>> maintainers.  This will indicate that the master branches are now ready
>> for rebasing onto where that is appropriate.  The derivative maintainers
>> will then rebase if required and determine if their branch has anything
>> worthy of an upload.  If so they will reply to the announcement adding
>> their branch to the versions to pushed this cycle.  The stable team will
>> then handle closing and uploading this branch with the main branches.
>> If the derivative branches are not ready in time for upload, they will
>> simply slip to the next cadance round.
>>
>> The current derivative branch maintainers are:
>>
>>   - smb: Lucid -ec2
>>   - ppisati: everything arm
>>
>> Comments?
> 
> Is this relevant/helpful for maintaining other kernels (e g the lowlatency stuff
> comes to mind), or is that a completely orthogonal problem to this one?
> 
It is probably slightly different. The main difference is the degree of support
promised. The topic branches we provide have that promise, while the community
maintained kernels have not. So we follow closely (or try to) the master branch,
while for the other there is nothing guaranteeing that there will be a matching
release for every ubuntu-kernel version. So it is more relaxed when things are
done or whether at all.

-Stefan




More information about the kernel-team mailing list