[Openembedded-architecture] Stable releases beyond one year

[Tim Orling]

> On Jan 11, 2017, at 11:25 AM, Paul Barker <paul at paulbarker.me.uk> wrote:
> 
> On Fri, 06 Jan 2017 15:52:24 +0000
> Richard Purdie <richard.purdie at linuxfoundation.org <mailto:richard.purdie at linuxfoundation.org>> wrote:
> 
>> Our current stable release policy is to maintain the stable release
>> branches for around a year. Maintain means merging patches, running
>> the branch through the autobuilder periodically and running the full
>> point release QA and release process.
>> 
>> We need to figure out the "what happens beyond this point?" question
>> and I owe Armin an answer to this.
>> 
>> My proposal is that at this point, the releases move to a "community
>> maintained" mode. The maintainer can continue if they wish, the change
>> would be that the changes get pushed to a "-community-lts" type repo
>> instead.
>> 
>> The reason for the different repo is to highlight there is a change in
>> process and in guarantees on the status of the release. Keeping the
>> autobuilders building old releases is actually very very hard and not
>> something we can commit to with current resources and I want to make
>> it clear to users that something changes at this point. Equally I
>> want to enable people to still collaborate on changes and share them,
>> rather than doing them individually.
>> 
>> How does that sound to people?
> 
> This sounds like a really good idea to me. There's definitely some
> duplication of effort here. Users currently need to choose between LTS
> from a commercial vendor (which is perceived as expensive) and
> backporting patches themselves. I think there's room for a middle
> ground, community LTS where things are done as a best-effort rather
> than with explicit guarantees.
> 
> I think if there is broad enough support for a community LTS, we should
> try to select a subset of the releases to maintain instead of spreading
> ourselves too thin. Personally I feel like choosing one community LTS
> version every 2 years would be a good compromise. E.g. Krogoth (2.1)
> becomes a community LTS in April when the official 12 month support
> expires but we skip morty, pyro and 2.4 then take 2.5 as the next
> community LTS. Each community LTS could be supported as a 'best effort'
> for up to 2 years, taking the total life of these releases out to 3
> years. That still leaves space for commercial vendors to provide longer
> duration support and guaranteed responses (instead of the community's
> 'best effort') as a value-add.
> 
> I think if we adopt this we should try to focus resources by not taking
> patches for branches which are not selected as community LTS versions
> after the initial 12 month maintenance period expires. We should also
> not take patches for community LTS versions after their 3 years of
> extended life expires. Otherwise I think we're again risking spreading
> limited resources too thin.
> 
> Part of the reason I'm still using daisy (1.6) at work is that it's
> very difficult to go to my manager and request time to port things
> forward to a new release, knowing that I'm going to have to do the same
> again within 12 months. If we could extend this out to porting forward
> to a community LTS release once every 2-3 years I think that would be
> much more achievable.
> 
> Anyone else think this is a sensible approach?

As a developer that lives on “master”, I find it hard to remember the context of older releases. That is human nature. When faced with an older product that was only supported in daisy or fido etc, I find myself missing tools/features that have been added since.

If I put on my Program Manager hat from a prior employer, I would totally agree with your 3 year plan. If that is not a long enough runway in today’s business market, then you __should__ be paying for an OSV (e.g. you are doing military hardware with a 30 year life cycle). Compare the cost of the OSV to the cost of your developers’ and field engineers’ time and I wonder what the bottom line is? My developer hat would of course say that the developers should be allowed to try to maintain a branch on “master”. One member of the team should be chosen for that as a substantial part of their role, even if it is not planned to be released. Fork it and forget it is a horrible model.You are obsolete on day one.

I wonder how much of the “pain” is because of vendor kernels? Please ask your vendors to upstream. If they don’t know how, point them to a consultancy that is highly skilled at that activity.

My $0.02.

> 
> Thanks,
> Paul
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org <mailto:Openembedded-architecture at lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture <http://lists.openembedded.org/mailman/listinfo/openembedded-architecture>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20170111/0b2e93e6/attachment-0002.html>