[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [lts-iwg] Instructions for projects to prepare LTS backports ?

Great. Unless I missed it I would suggest to add it on the eclipsecon sessions, or sessions schedule pages.

 

From: lts-iwg-bounces@xxxxxxxxxxx [mailto:lts-iwg-bounces@xxxxxxxxxxx] On Behalf Of Andrew Ross
Sent: March-07-13 9:03 AM
To: lts-iwg@xxxxxxxxxxx
Subject: Re: [lts-iwg] Instructions for projects to prepare LTS backports ?

 

Pascal,

Great question. The LTS information session on Tuesday afternoon is open to all. In fact, it is even open to people not registered for EclipseCon.

The agenda, and free registration is available from here:
http://lts.eclipse.org/content/lts-working-group-information-session
(if your name is already listed as attending, you do not need to re-register)

Andrew

On 03/05/2013 10:06 AM, Pascal Rapicault wrote:

Andrew,

 

Will you or anyone else from the LTS initiative be doing a presentation, open to everyone, at EclipseCon ?

 

Pascal

 

 

 

From: lts-iwg-bounces@xxxxxxxxxxx [mailto:lts-iwg-bounces@xxxxxxxxxxx] On Behalf Of Andrew Ross
Sent: March-01-13 4:37 PM
To: lts-iwg@xxxxxxxxxxx
Subject: Re: [lts-iwg] Instructions for projects to prepare LTS backports ?

 

Martin,

Confirmed regarding the pull model & generally minimizing community development disruption/hindrance/ by LTS. A natural tension/pressure to converge caused by merge-hell is a good thing in my opinion.

I think it makes a lot of sense to have the Architecture council involved. In the ideal scenario, we can have a single standard layered on top of any project-specific conventions to again allow projects the freedom to do what they need to but try and minimize confusion and errors in LTS-land.

Thanks again for the interest, thoughts, and support.

Andrew

On 02/22/2013 09:50 AM, Oberhuber, Martin wrote:

Thanks Andrew,

 

The “pull” model makes perfect sense. So I understand that for now, you’ll let every project do what they want and have LTS pull in fixes when needed. Which might of course get painful when trying to pull targeted fixes which sit on top of an undesired change, for instance.

 

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.

 

That’s exactly what I was alluding to. Let me know if you want Architecture Council support in defining and promoting those branching and tagging conventions. I could invite you or some other LTS members to an AC monthly meeting to talk about the problem space, or we could have a small focused meeting at EclipseCon to start this.

 

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 Andrew Ross
Sent: Friday, February 22, 2013 3:35 PM
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

 

 




 




_______________________________________________
lts-iwg mailing list
lts-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/lts-iwg