Re: [lts-iwg] Instructions for projects to prepare LTS backports ?

["Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>]

Martin,

 

Thanks for the clarification. I am no longer confused :)

 

Mike Milinkovich

mike.milinkovich@xxxxxxxxxxx

+1.613.220.3223

 

From: Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx]
Sent: February-22-13 10:06 AM
To: mike.milinkovich@xxxxxxxxxxx; Long-Term Support IWG
Subject: RE: [lts-iwg] Instructions for projects to prepare LTS backports ?

 

Hi Mike,

 

No Intel / Wind River did not join the IWG and does not intend to at this time.

 

But in the past it was always said that the LTS initiative depended on the support of all project committers.

After all, any original bug fixes need to live in the project repositories – anything else would be against the spirit of the EPL from what I understand.

 

My request was trying to offer help here as an individual project committer who just made a relevant fix, and as an AC member.

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6

 

From: lts-iwg-bounces@xxxxxxxxxxx [mailto:lts-iwg-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
Sent: Friday, February 22, 2013 3:38 PM
To: 'Long-Term Support IWG'
Subject: Re: [lts-iwg] Instructions for projects to prepare LTS backports ?

 

I must be missing something. I thought the LTS forge was going to be for the use of the companies involved in the IWG. Did Intel/Wind River join the IWG?

 

Mike Milinkovich

mike.milinkovich@xxxxxxxxxxx

+1.613.220.3223

 

From: lts-iwg-bounces@xxxxxxxxxxx [mailto:lts-iwg-bounces@xxxxxxxxxxx] On Behalf Of Andrew Ross
Sent: February-22-13 9:35 AM
To: Long-Term Support IWG
Subject: Re: [lts-iwg] Instructions for projects to prepare LTS backports ?

 

Hi Martin,

Thank you for the great question.

At the Foundation, we want to strive for a similar approach to how we support the community and that is to provide infrastructure and let the (LTS) stakeholders choose how to use it to meet their needs. That said, the work flows for LTS are complicated enough that to keep things progressing, I've been exerting a little guidance based on my experience to provide a starting point we can evolve from.

The current view is that the LTS group will pull fixes in two main ways, LTS members (premium & up) will have the option of pulling fixes:

1.      directly to their company specific area in LTS via. their maintenance committers. This lets them pick and choose the fixes they deploy even if there isn't consensus across the change control committee yet. OR

2.      into LTS-central via. the change control committee & maintenance integrators which actually do the propagation, testing, etc. in a space common to all LTS members.

These two paths are related in that content pulled in via. 1 will be up for consideration in 2. Also, content from 2 will be strongly considered for 1. Simply put, the closer a company's LTS area is with LTS central, they more they benefit from shared efforts and less integration pain. We need to support both paths.


At a more detailed level, we shouldl see standards for branching and tagging emerge to support LTS. Today, some developers work on multiple projects. It's likely in a maintenance context we may see people working on a wider span of projects. Differences in branching and tagging conventions across projects has high potential to cause much confusion. I'd very much like to see active discussion here to see if we can arrive at a consensus on such conventions that many projects can support and implement.

From an individual developer's perspective. As a committer, you can request read-only access to the projects you work on in LTS. You can get read-write access via. an LTS member if they make you one of their maintenance committers and/or maintenance integrators.

Andrew

On 02/22/2013 03:38 AM, Oberhuber, Martin wrote:

Hi Andrew,

 

It’s great to see the LTS website up !

 

With Juno SR2 being released today, projects will very soon consider backporting bug fixes into LTS maintenance streams.

In fact, I’ve happened to fix a regression bug in the TM Terminal yesterday which would be a candidate for the LTS stream.

And I know that Platform has several bug fixes scheduled for 4.2.2+.

 

Are there any instructions already for projects how they should prepare backport streams in their repositories ?

Is the LTS group going to “pull” individual fixes or will projects be asked to “push” whatever they find appropriate to LTS ?

If these things are not clear yet, is there an ETA for clarification ?

 

As projects might be considering their branching strategy for Juno SR2+ / LTS fixes these days, now would be a good time to shed some light …

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6