SimRel/ChangingProcessAndTiming

How to change Sim Rel Process and Timing

This is intended as a "working document" only ... to capture ideas on how to change the "Simultaneous Release" process and timing.

Notes here should focus not only on potential solutions, but also a crisp statement what the Simultaneous Release is meant to be, who the audience is, what goals are meant to be achieved, what "good things" about current process must be maintained, and similar issues. In some ways, this is meant to be a high level summary of what is sometimes mentioned in mailing lists, bugzilla entries, and meeting minutes.

The ultimate goal, of this document, is to come up a new process proposal, perhaps partially for Mars "SR" releases, but primarily for "Neon" time frame, and even, it is hoped, can help guide continuous improvement in the future.

History

- Review of original motivations and problems solved by current process and schedule.

-- Contrasting "styles" of "releases": Our yearly release was intended to be rock-solid release, that commercial adopters could count on being released on a predictable time, with a predictable level of quality -- so that their own money-making support processes would be predictable, and long term.

-- Another style: Some OS Projects like to have a "release" very frequently, typically at semi-random times, and often very frequently (from "weekly") to "several months"). Notice the parallel to our "I-builds" and "Milestone (Stable) builds).

--- These releases are typically done when either "significant bugs in previous release had been fixed" or

--- There had been "enough new features added" that "things were ready").

-- An interesting (casual) observation: when these "frequent release" OS Projects were largely driven by a "service" organization, there is often one "release" (perhaps a year old, or so) that is the one (and only) one that they offered service contracts for ... which parallels our own yearly releases. (In other words, they use the word "release" to have more than one meaning.)

• - Given the above, our "solution" was to provide a (voluntary) Simultaneous Release train once per year, while at the same time, emphasizing that individual projects could still release whenever they wanted.

• - Short review of "pre-Callisto" days, to avoid repeating past mistakes; (Names and examples are a fictional melding of several cases). Platform released in June. TPTP and CDT a month or two later, WTP a month or two later. Only at that time, was a bug discovered in the Platform (by WTP nearing release) such that they could not release until SR1. Platform releases SR1 in September, WTP can now release. Only then was it observed that some regression was introduced that prevented CDT from working with the Platform SR1. So, CDT might hurry up with their SR1, or adopters would all have to patch a mix and match of components to make their product schedule. In the end, adopters could come up with a product, but it was pretty unlikely users could install other things from Eclipse into it, since there was no "standard" release to build on top of. Similar problem for other plugin providers, inside and outside Eclipse ... it was hard to find a stable, consistent set of things that "worked together", and even when they could, imagine the instructions to the end users on how many update sites to go to, getting precise versions of things (might be most recent, but might be down level) all to "make something work" ... and then no confidence that other things would work with that collection. So, it was thought "same schedule" and "one update site" was a good start at solving these early problems.

• - Much has changed since those pre-Callisto days (such as rate of change has slowed) but ... that the principle is the same and is still valid.

• - One reason, originally, that we had "integration over many milestones" as *the* key requirement (it was the only requirement, nearly, in Callisto) was A. to find bugs in OTHERS code (for example, some change in the Platform might not be reproducible if using only the Platform, but it would easily prevent WTP from working correctly, and if discovered "late", then there would be no time to fix it before the planned release date. B. Many of the bugs found in this situation are subtle, due to the many "interacting components" (even though only 20 or so, during Callisto). No one could possibly find them during any sort of quick smoke test, or even a few weeks of "testing one component"; but only when used in "real life" use-cases and workloads ... and we are gratefully to our community of early-adopter users, for trying to do just that, and providing that valuable feedback over a period of many months.

• - The other, "checklist" requirements have been added to or changed over the years for some items. These typically fall into categories of "minimum" to-do items, to work in one repository, without making us look silly (or, security related) and then also into a category of things that allow better adoption by other projects and commercial adopters.

The Future

Statement of Problem

• There is some (ongoing) concern that "we" (the Eclipse Foundation) need ability to "release more often" or "with very short cycle". Some have mentioned "once every 6 months". Some, in the past, have said "once a year is too frequent, and should be once every two years" (as LTS was originally proposed to support [current policy is a little less formal, mostly "any SR2" and sometimes even SR1, as I understand it]). And, some projects want (or, do) release every month or two (especially new projects). How can we be "all things, to all people"? (Or, at least, get much closer than we are now).

• Our Policy of new projects joining in SR's was intended to be one step in that direction. (And, at first, many said that was enough ... that satisfied needs, that I could even take the on-going discussion off of the agenda [reference] ... but now ...

-- Some have mentioned "the timing" is still not right, and need something between SR1 and SR2.

-- Some have mentioned that "SR" (Service Release) is the wrong name, if it is going to contain new projects and new features. (And, not sure if it is that incorrect 'SR' naming, but it does seem it is a widely misunderstood policy -- by even Planning Council members.

--- We discussed naming in previous meeting [find reference].

- The EPP packages have been so successful, that some now believe that a project "releasing when ever it wants to" does not mean anything (or, much) ... it only means something if EPP can release when ever it wants to.

-- Similarly, it is hard for a project to "update" just their one component in an EPP package, for part technical, and part policy reasons.

• The EPP packages have been so successful, that "everyone" wants to be in an EPP package -- so much so, they are nearly a marketing tool.

-- Off topic, maybe, but this is oddly parallel to early days, when "everyone wanted to be in the Platform" since that was the "main thing" at Eclipse, that everyone installed. Are we now seeing the same thing happen to EPP packages? Are non-EPP components second class citizens? That was never the intent. The EPP packages were meant to merely provide a better "out of the box" usability experience, oriented to certain audiences, but it was expected that users could and should still "customize" that by adding what ever other function they'd like.

-- The "Simultaneous Release" repository was intended (in part) to make it "easier to discover things" that were available, instead of having to "look all over the place".

--- Probably several reasons why that's not working too well?

--- And now we also have "The Market Place" -- yet another place to look? Or, satisfying needs of a certain class of user? (I think the latter).

-- Should we avoid having too much in EPP packages? Or, put in as much as we can? [Without usage statistics, it is impossible to know.]

-- The "capabilities" mechanism in the Platform was also supposed to help make things easy to progressively discover, but it never caught on.

• Leaf versus Core: we currently do not have a good separation of "leaf" vs "core" component -- and perhaps this is not possible. It could be argued it is easier for a "pure leaf" component to update/release more frequently, than "core" components, since they would have less chance of breaking others in release train. But, they could, still break adopters (and in theory still break core components functionality, due to the nature of "plugins and OSGi". There are often "tangled" relationships making the distinction between "leaf" and "core" multi-faceted instead of a clear binary or hierarchical distinction.

Constraints

• Developers work load
• IP work load (and work flow)
• Marketing

What is required for (any) solution?

• Improved automation
• More "self service"
• More automated testing

Possible solutions

• See Doug's mailing list post for one approach.