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 techno...
Members	
  of	
  Eclipse
10	
  Years	
  in	
  a	
  Row
So	
  Eclipse	
  Has...
• Millions	
  of	
  users	
  
• Thousands	
  of	
  products	
  
• One	
  thousand	
  developers	
 ...
So	
  Eclipse	
  Has...
• Millions	
  of	
  users	
  
• Thousands	
  of	
  products	
  
• One	
  thousand	
  developers	
 ...
Mission-­‐critical	
  solutions	
  	
  
may	
  live	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  forever	
  
Eclipse	
  projects...
©AIRBUSFRANCES.A.S.Tousdroitsréservés.Documentconfidentiel.
Open Source Day SIEMENS-VDO 27th September 2006 page
Our const...
The	
  Eclipse	
  Long-­‐Term	
  Support	
  Program
Slide	
  Credit:	
  	
  
Karsten	
  Schmidt

September	
  2012
Brief History
The	
  LTS	
  Eco-­‐System
• Consumer	
  driven	
  
• Creates	
  business	
  opportuniVes	
  	
  
– for	
  integrators	
  ...
LTS	
  Technology	
  (1)	
  	
  
Common	
  Build	
  Infrastructure
• provides	
  means	
  to	
  unify	
  builds	
  for	
  ...
LTS	
  Technology	
  (2)	
  
Infrastructure
• Shadow	
  of	
  the	
  standard	
  Eclipse	
  infrastructure	
  
• Private	
...
An	
  Experience	
  Report	
  from...
Markus	
  Knauer,	
  EclipseSource	
  
!
!
!
!
!


Eclipse	
  Remote	
  Application	...
Choosing	
  to	
  Use	
  LTS
Many	
  companies	
  build	
  many	
  products	
  on	
  Eclipse	
  technology.	
  
Each	
  pr...
Which	
  Bugs	
  Do	
  We	
  Fix?
Bugs	
  are	
  typically	
  identified	
  by	
  either	
  customer	
  reports,	
  or	
  ...
Preparing	
  Code	
  Changes
The	
  LTS	
  infrastructure	
  has	
  a	
  private	
  Gerrit	
  system	
  for	
  code	
  sto...
Pushing	
  Changes
The	
  change	
  is	
  then	
  committed	
  (git	
  push)	
  by	
  a	
  maintenance	
  committer	
  wit...
Building	
  the	
  Code
For	
  the	
  LTS-­‐Central	
  code	
  stream	
  there	
  is	
  an	
  automated	
  build	
  done	
...
Getting	
  the	
  Fix	
  to	
  Customers
Once	
  a	
  build	
  is	
  done,	
  LTS	
  is	
  done.	
  
New	
  bundles	
  gen...
Timeline	
  of	
  a	
  Fix
2014-­‐01-­‐29	
  17:51	
  	
   Production	
  critical	
  bug	
  in	
  RAP	
  2.1	
  
2014-­‐01...
Summary
LTS	
  allows	
  us	
  to	
  take	
  an	
  existing	
  code	
  change	
  and	
  build	
  it	
  against	
  the	
  p...
More	
  InformaVon
• Website:	
  hZp://lts.eclipse.org	
  
• Marketplace:	
  hZp://marketplace.eclipse.org	
  
• WG	
  cha...
ThankYou
ralph.mueller@eclipse.org	

@ralph_mueller	

!
Contains materials from Steve Francisco, IBM 	

and Markus Knauer,...
Long Term Support the Eclipse Way
Long Term Support the Eclipse Way
Long Term Support the Eclipse Way
Long Term Support the Eclipse Way
Long Term Support the Eclipse Way
Upcoming SlideShare
Loading in …5
×

Long Term Support the Eclipse Way

689 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
689
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Long Term Support the Eclipse Way

  1. 1. Open Source 
 Long-Term Support The Eclipse Way Ralph Müller
 Eclipse Foundation Javaland Conference 25.April 2014
  2. 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!
  3. 3. Members  of  Eclipse
  4. 4. 10  Years  in  a  Row
  5. 5. 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
  6. 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. 7. Mission-­‐critical  solutions     may  live                    forever   Eclipse  projects  don’t Support  ends  after  9  months  with  SR2* But  …
  8. 8. ©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
  9. 9. The  Eclipse  Long-­‐Term  Support  Program Slide  Credit:     Karsten  Schmidt
 September  2012
  10. 10. Brief History
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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)
  15. 15. 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)
  16. 16. 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.
  17. 17. 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
  18. 18. 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.
  19. 19. 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.
  20. 20. 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
  21. 21. 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
  22. 22. 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.
  23. 23. 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!
  24. 24. ThankYou ralph.mueller@eclipse.org @ralph_mueller ! Contains materials from Steve Francisco, IBM and Markus Knauer, EclipseSource

×