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
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?

Thanks,
Paul
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture