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