Re: Stable releases beyond one year

Tim Orling <timothy.t.orling@...>

On Jan 11, 2017, at 11:25 AM, Paul Barker <paul@...> wrote:

On Fri, 06 Jan 2017 15:52:24 +0000
Richard Purdie <richard.purdie@...> 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

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.

Openembedded-architecture mailing list

Join to automatically receive all group messages.