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