The Eclipse Long Term Support program, how we got there and what it is. With materials from Markus Knauer / EclipseSource and Steve Francisco / IBM from EclipseCon NA 2014

1. Open Source
Long-Term Support
The Eclipse Way
Ralph Müller
Eclipse Foundation
Javaland Conference
25.April 2014

2. By 2012, 80 per cent of all commercial software will include
elements of open-source technology.
!
Many open-source technologies are mature, stable and well
supported.
!
They provide significant opportunities for vendors and users to
lower their total cost of ownership and increase returns on
investment.
!
! ! ! ! ! ! ! ! ! ! ! Gartner Group, 2008!

4. Members
of
Eclipse

5. 10
Years
in
a
Row

6. So
Eclipse
Has...
• Millions
of
users
• Thousands
of
products
• One
thousand
developers
• Hundreds
of
companies,
hundreds
of
projects
• Predictable
schedules
• World
class
intellectual
property
management
• 18
employees
(as
we
speak)
• Zero
product
managers

7. So
Eclipse
Has...
• Millions
of
users
• Thousands
of
products
• One
thousand
developers
• Hundreds
of
companies,
hundreds
of
projects
• Predictable
schedules
• World
class
intellectual
property
management
• 18
employees
(as
we
speak)
• Zero
product
managers

8. Mission-­‐critical
solutions
may
live
forever
Eclipse
projects
don’t
Support
ends
after
9
months
with
SR2*
But
…

10. ©AIRBUSFRANCES.A.S.Tousdroitsréservés.Documentconfidentiel.
Open Source Day SIEMENS-VDO 27th September 2006 page
Our constraints
!
One example : AIRBUS A300
!
• Program began in 1972 and
will stop in 2007
2007-1972 = 35 years...
!
• Support will last until 2050
2050-1972 = 78 years !!!
On board software development for very long lifecycle
products

11. The
Eclipse
Long-­‐Term
Support
Program
Slide
Credit:
Karsten
Schmidt
September
2012

12. Brief History

13. The
LTS
Eco-­‐System
• Consumer
driven
• Creates
business
opportuniVes
– for
integrators
(worldwide,
SLA
oriented)
– small
and
medium
sized
expert
companies
– individual
commiZers
• Infrastructure
is
financially
supported
by
parVcipaVng
support
providers
• Governance
is
provided
by
LTS
working
group

15. LTS
Technology
(1)
Common
Build
Infrastructure
• provides
means
to
unify
builds
for
Eclipse
project(s)
• makes
it
easy
to
• copy
and
modify
source
• build
and
test
• post
changes
for
review
• sign
so^ware
• uses
git,
Gerrit,
Hudson,
Tycho
and
Maven

16. LTS
Technology
(2)
Infrastructure
• Shadow
of
the
standard
Eclipse
infrastructure
• Private
repository
for
each
LTS
member
• Shared
repository
for
all
LTS
members
• Private
bug-­‐tracking
system
(under
discussion)
• LTS
marketplace
• LTS
website,
Mailing
List

17. An
Experience
Report
from...
Markus
Knauer,
EclipseSource
!
!
!
!
!
Eclipse
Remote
Application
Platform
(RAP)
LTS
Releases
since
September
2013
(RAP
2.1)
Steve Francisco, IBM
!
!
!
!
!
Eclipse
PlatformLTS
Release
since
June
2013
(Eclipse
4.2)

18. Choosing
to
Use
LTS
Many
companies
build
many
products
on
Eclipse
technology.
Each
product
needs
to
issue
fixes
and
updates
over
its
lifespan.
Delivering
fixes
in
open
source
components
requires
1. Domain
expertise
in
the
code
2. Legacy
build
systems
to
build
the
old
code
base
Even
if
a
company
has
the
expertise
to
make
code
changes,
it
typically
does
not
have
the
hardware,
manpower
or
desire
to
maintain
a
repeatable
build
infrastructure
to
rely
on.
LTS
offers
the
answer,
starting
with
the
Eclipse
Juno
based
products.
This
report
describes
the
use
of
LTS
by
a
self-­‐service
provider
(just
one
mode
of
operation
available
with
LTS)

19. Which
Bugs
Do
We
Fix?
Bugs
are
typically
identified
by
either
customer
reports,
or
internal
testing.
Eclipse
bugzilla
defects
are
opened
to
track
problems
in
Eclipse
code.
Only
severe
problems
warrant
the
expense
of
delivering
a
patch.
Bug
fixes
often
appear
first
against
the
HEAD
development
stream:
Backports
Some
bugs
are
unique
to
the
older
release
so
need
individual
attention
in
the
older
code
stream.
Fixes
get
committed
to
Eclipse
Platform’s
R4_2_maintenance
stream
or
to
the
RAP
2.x-­‐maintenance
stream.
This
is
public
(non-­‐LTS)
and
satisfies
the
EPL
requirement
to
make
all
code
changes
available.

20. Preparing
Code
Changes
The
LTS
infrastructure
has
a
private
Gerrit
system
for
code
storage.
This
is
private
to
LTS
members
so
code
must
be
separately
committed
before
LTS
builds
will
see
the
fixes.
‘git
cherry-­‐pick’
is
used
to
grab
a
particular
code
change
from
the
community
Git
repository
for
the
particular
fix
needed.
Backports
from
HEAD
by
cherry
picking:
Java
code
is
easy
to
merge
(most
of
the
time)
Compressed
JavaScript
code,
XML
data,
binaries
need
special
attention

21. Pushing
Changes
The
change
is
then
committed
(git
push)
by
a
maintenance
committer
with
authorization
in
LTS
to
either
a
private
company-­‐specific
repository
-­‐
for
customer-­‐specific
fixes
the
common
LTS-­‐Central
repository
-­‐
for
common
fixes
!
If
they
are
stored
in
LTS-­‐Central,
all
LTS
members
can
have
direct
access
to
the
fixes
and
resulting
builds.

22. Building
the
Code
For
the
LTS-­‐Central
code
stream
there
is
an
automated
build
done
twice
daily
for
Eclipse
Platform.
Hudson
is
used
to
manage
the
builds.
LTS
uses
CBI
giving
the
same
build
output
that
were
used
to
form
the
original
Eclipse
Juno
builds.
Build
errors
are
easy
to
view
if
there
is
a
failure.
Typical
LTS
build
maintenance
includes
updating
external
references
(e.g.
p2
URLs)
Dedicated
resources
at
Eclipse
Foundation
monitor
the
build
system
and
can
be
contacted
if
a
mechanical
issue
occurs.
Binaries
from
a
successful
build
can
also
be
taken
from
the
web
page.

25. Getting
the
Fix
to
Customers
Once
a
build
is
done,
LTS
is
done.
New
bundles
generated
by
LTS
can
now
be
incorporated
into
waiting
product
fixpacks
for
delivery
to
customers.
Feature
patches
are
created
to
direct
Eclipse
to
load
the
fixed
bundles
in
place
of
originals.
All
bundles
are
signed
for
security
with
a
certificate
and
delivered
to
the
product
team
waiting
for
the
fix.
Testing
and
final
packaging
is
done
so
changes
can
safely
be
delivered
to
customers

26. Timeline
of
a
Fix
2014-­‐01-­‐29
17:51
Production
critical
bug
in
RAP
2.1
2014-­‐01-­‐29
18:45
RAP
Team
finishes
analysis
2014-­‐01-­‐30
11:58
First
version
of
bug
fix
pushed
2014-­‐01-­‐30
17:07
Second
version
for
corner
cases
pushed
2014-­‐01-­‐30
17:13
LTS
build
finishes
successfully
2014-­‐01-­‐30
17:41
Fix
delivered
to
customer

27. Summary
LTS
allows
us
to
take
an
existing
code
change
and
build
it
against
the
proper
environment
rapidly.
Not
having
to
construct
&
maintain
a
build
system
means
we
focus
purely
on
the
fix.
We
are
able
to
turn
around
a
fix
within
a
day
in
many
cases
once
development
is
ready
with
a
fix.
Using
LTS
gives
us
a
reliable
infrastructure
with
experienced
support.

28. More
InformaVon
• Website:
hZp://lts.eclipse.org
• Marketplace:
hZp://marketplace.eclipse.org
• WG
charter:
hZp://lts.eclipse.org/charter
• Current
members:
hZp://lts.eclipse.org/members
• Mailing
list:
hZps://dev.eclipse.org/mailman/lisVnfo/lts-­‐iwg
!
Eclipse
LTS
is
work-­‐in-­‐progress.
Let
us
know
what
you
think!

29. ThankYou
ralph.mueller@eclipse.org
@ralph_mueller
!
Contains materials from Steve Francisco, IBM
and Markus Knauer, EclipseSource