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