long term support the eclipse way
DESCRIPTION
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 2014TRANSCRIPT
Open Source Long-Term Support
The Eclipse Way
Ralph Müller Eclipse Foundation
Javaland Conference 25. April 2014
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!
Members of Eclipse
10 Years in a Row
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
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
Mission-‐critical solutions may live forever
Eclipse projects don’t
Support ends after 9 months with SR2*
But …
© A
IRB
US
FR
AN
CE
S.A
.S. T
ous
droi
ts ré
serv
és. D
ocum
ent c
onfid
entie
l.
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
The Eclipse Long-‐Term Support Program
Slide Credit: Karsten SchmidtSeptember 2012
Brief History
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
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
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
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)
Choosing to Use LTSMany 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)
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.
Preparing Code ChangesThe 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
Pushing ChangesThe 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.
Building the CodeFor 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.
Getting the Fix to CustomersOnce 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
Timeline of a Fix2014-‐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
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.
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!
Thank You
[email protected] @ralph_mueller
!Contains materials from Steve Francisco, IBM
and Markus Knauer, EclipseSource