[cip-dev] CIP Kernel release cadence

[cip-dev] CIP Kernel release cadence

[Chris Paterson]

Hello Ben,

Do you have a plan for when future releases of the CIP Kernel will be made?

It would be good to have a fixed release cadence or roadmap, so people using the Kernel can plan their activities accordingly.


Kind regards, Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20170620/979b60f1/attachment.html>

[cip-dev] CIP Kernel release cadence

[Ben Hutchings]

On Tue, 2017-06-20 at 09:12 +0000, Chris Paterson wrote:
> Hello Ben,
>
> Do you have a plan for when future releases of the CIP Kernel will be
> made?
>
> It would be good to have a fixed release cadence or roadmap, so people
> using the Kernel can plan their activities accordingly.

I expect to release about every month, and whenever there's an urgent
security update (which there will be soon, for the "stack clash" issue).

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

[cip-dev] CIP Kernel release cadence

[Agustin Benito Bethencourt]

Hi Chris,

I think I mentioned before some of the below arguments when this topic 
was risen months ago. It is a good time to publish them here.

On 20/06/17 17:18, Ben Hutchings wrote:
> On Tue, 2017-06-20 at 09:12 +0000, Chris Paterson wrote:
>> Hello Ben,
>>
>> Do you have a plan for when future releases of the CIP Kernel will be
>> made?
>>
>> It would be good to have a fixed release cadence or roadmap, so people
>> using the Kernel can plan their activities accordingly.
>
> I expect to release about every month, and whenever there's an urgent
> security update (which there will be soon, for the "stack clash" issue).

I would like to keep flexibility here, that is, do not tight ourselves 
to releases yet for a variety of reasons. These are the main ones I can 
think of right now:

* We are in an LTS phase. Defining a cadence at this point might 
reinforce the idea that our kernel maintenance process is somehow 
different than LTS when, except for a few packages, it is not yet. That 
was intentional.

* I would like to be able to consistently test the kernel, even with a 
single test, before claiming to make releases, that is, before making a 
public commitment on any delivery process. The expectations can be 
higher that we can commit to.

* We do not know at this point what the maintenance cycle is going to be 
from the kernel community. I am not suggesting that we have to follow 
it, but before defining our cadence, I would have a clear idea about 
what upstream will do.

* A kernel release for SLTS has severe implications in other areas, like 
the testing tools, testing results, tests, etc. We need also to 
freeze/store/release them, together with the build instructions, 
metadata, artifacts, source code.... In other words, we need to define 
what "a release" means for CIP and how much effort requires.

* With the above and the fact that we are starting to put effort in -RT, 
I wonder if we will talk about releasing the CIP kernel or we will talk 
about releasing the CIP platform (assuming that at the beginning the 
kernel is the main bit).

Defining a release today might play against us in a year or two.

Once this said, if Members require at this point a cadence, we will 
provide one but I think that sticking to LTS cycle until Feb'18 and 
assuming that we will catch up every 4-8 weeks is the way to go. Once 
the 4.4 maintainer is published, let's talk to him/her and take decisions.

Is there a specific reason why you need a cadence now beyond what LTS 
provides? I am trying to understand the details in order to think about 
a solution for Renesas compatible with the above.

Best Regards

-- 
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito at codethink.co.uk

[cip-dev] CIP Kernel release cadence

[Chris Paterson]

Hello Agustin,

Thank you for your feedback, apologies for the delayed response.

> From: Agustin Benito Bethencourt [mailto:agustin.benito at codethink.co.uk]
> Sent: 20 June 2017 18:06
> 
> Hi Chris,
> 
> I think I mentioned before some of the below arguments when this topic
> was risen months ago. It is a good time to publish them here.
> 
> On 20/06/17 17:18, Ben Hutchings wrote:
> > On Tue, 2017-06-20 at 09:12 +0000, Chris Paterson wrote:
> >> Hello Ben,
> >>
> >> Do you have a plan for when future releases of the CIP Kernel will be
> >> made?
> >>
> >> It would be good to have a fixed release cadence or roadmap, so
> >> people using the Kernel can plan their activities accordingly.
> >
> > I expect to release about every month, and whenever there's an urgent
> > security update (which there will be soon, for the "stack clash" issue).
> 
> I would like to keep flexibility here, that is, do not tight ourselves to releases
> yet for a variety of reasons. These are the main ones I can think of right now:
> 
> * We are in an LTS phase. Defining a cadence at this point might reinforce the
> idea that our kernel maintenance process is somehow different than LTS
> when, except for a few packages, it is not yet. That was intentional.
> 
> * I would like to be able to consistently test the kernel, even with a single
> test, before claiming to make releases, that is, before making a public
> commitment on any delivery process. The expectations can be higher that
> we can commit to.
> 
> * We do not know at this point what the maintenance cycle is going to be
> from the kernel community. I am not suggesting that we have to follow it,
> but before defining our cadence, I would have a clear idea about what
> upstream will do.
> 
> * A kernel release for SLTS has severe implications in other areas, like the
> testing tools, testing results, tests, etc. We need also to freeze/store/release
> them, together with the build instructions, metadata, artifacts, source
> code.... In other words, we need to define what "a release" means for CIP
> and how much effort requires.

This is a good point. I guess I was referring to rebasing the CIP Kernel itself to the latest LTS tag, and when this would be done. E.g. LTS tag + x weeks?

> 
> * With the above and the fact that we are starting to put effort in -RT, I
> wonder if we will talk about releasing the CIP kernel or we will talk about
> releasing the CIP platform (assuming that at the beginning the kernel is the
> main bit).

I think that the CIP Kernel could/should be updated constantly, like LTS is now.

Periodically a complete 'CIP platform' release should be made. I think this should be done to a schedule so that users of the CIP project can plan their activities accordingly.

> 
> Defining a release today might play against us in a year or two.
> 
> Once this said, if Members require at this point a cadence, we will provide
> one but I think that sticking to LTS cycle until Feb'18 and assuming that we will
> catch up every 4-8 weeks is the way to go. Once the 4.4 maintainer is
> published, let's talk to him/her and take decisions.
> 
> Is there a specific reason why you need a cadence now beyond what LTS
> provides? I am trying to understand the details in order to think about a
> solution for Renesas compatible with the above.

Is there an actual release cycle for LTS? As far as I can see, new releases are made randomly.

Kind regards, Chris

> 
> Best Regards
> 
> --
> Agustin Benito Bethencourt
> Principal Consultant - FOSS at Codethink agustin.benito at codethink.co.uk