Planning Council/March 24 2013

From Eclipsepedia

Jump to: navigation, search

Contents

Logistics

Meeting Title: Planning Council Meeting
Date & Time: Sunday, March 24, 2013, at 1400 Eastern
Face-to-Face. No Dial-in. Room: South End, on the Plaza Level (top floor) of the World Trade Center.
Note: MeetGreen will be at the venue setting up registration in case you need anything.

Members and Attendees

PMC (and Strategic) Reps
Chris Aniszczyk Technology (PMC) No
John Arthorne Eclipse (PMC) Yes
Steffen Pingel Mylyn (ALM) PMC No (not attending EclipseCon and Mik is not available on Sunday)
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC) Yes
Adrian Mos SOA (PMC) No (flight schedule)
Ed Merks Modeling (PMC) No
Ian Bull Rt (PMC) Yes
David Williams WTP (PMC) (appointed Chair) No.
Gary Xue Birt (PMC)
Wayne Beaton Eclipse Foundation (appointed) Yes
Strategic Reps
Cedric Brun OBEO (Strategic Developer) No
Neil Hauge Oracle (Strategic Developer) Yes
Kaloyan Raev SAP AG (Strategic Developer) No (not attending EclipseCon)
Markus Knauer Innoopract (Strategic Developer) Yes
Achim Loerke (Markus Tiede) BREDEX (Strategic Developer) Yes
Shawn Pearce Google (Strategic Developer) Yes
(PMC rep) Actuate (Strategic Developer) X
(PMC rep) IBM (Strategic Developer) X
Inactive
[no name] CA Inc. (Strategic Consumer) X

Note: "Inactive" refers to Strategic Members or PMCs we have not heard from for a while, and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.

Note: feel free to correct any errors/omissions in above attendance record.
Y = Yes, attended
N = No, did not
R = regrets sent ahead of time
D = delegated
X = not expected

Minutes

Policy on new releases joining SR

  • We agreed on David's proposed policy from previous call: "The new release must be in RC1 builds for the SR, must have released one month prior to that RC1, and must be willing/able to test and provide a quick maintenance release if last minute problems found."


Build reproducibility

We had a lengthy discussion about the issue of reproducibility of the aggregation build. Ideally aggregator should be idempotent: multiple runs of the aggregator on the same aggregation input files should produce the same result. In practice, this does not work. One problem is that people contribute a composite repository URL, and then just update the children any time they want without updating their contribution file. There are a number of drawbacks to this:

  • It is very difficult to do a careful respin of only one component to address a critical bug, such as the case with EGit in Juno SR2. You can't be certain that nothing else will creep in.
  • You can't diff two states of the aggregator and see exactly what projects have changed.
  • After the release is over it can never be reproduced again
  • Projects end up accidentally contributing the wrong thing to the aggregator

There was general agreement that we should strive to make the aggregator idempotent. One step in this direction is not allowing composite repositories to be used as input. There is a perception that b3 files are brittle and projects are afraid of breaking things, it is very hard to know if you made your changes correctly. If there was a simple way to update the repository for each aggregation build there would be less incentive to "cheat" with composite repositories.

A common convention on p2 repository addresses could help. Some parts of the manual updating could be automated if all projects had a normalized repository path like <projectName>/milestones/kepler/m5 for example.

Another possible solution is that the aggregation mirror *all* the data as a first step. Then that mirroring could be turned off for emergency rebuilds. This also handles the fact that projects might not have durable p2 repositories and after the release may delete that repository and make their aggregator input invalid. Or we just capture and save the metadata such as bundle version numbers and we can validate that nothing has changed except what we expect to change. This could also be used as a way to control/enforce that projects are providing consistent/durable inputs.

Release train rules

There is a general perception that there are "too many rules" for joining the release train. Some projects are declining participation because they see it as unnecessary process overhead. In reality the non-negotiable rules are few, and there is a long list of "should do" items that make the overall rules document look daunting. The suggestion was made to split this into two distinct documents such as "release train rules", and "release train guidelines". We should also strive to make the rules less wordy. Keep the rules very short, with links as appropriate to other documents for more details. Someone should be able to sit down and read through all the rules without being overwhelmed.

Release train rhythm

We had a very general discussion about the current "one plus two" rhythm of the release train. The original intent is that there was one annual release with new features, and two service releases with only bug fixes. This evolved over time and now some projects just treat it as three release windows into which they can put whatever new release they want. The problem is that having new features only once a year isn't fast enough for some communities. It is fine for stable projects but not for new projects or projects working in areas with rapid innovation.

The idea was floated of having more than three release windows, and it would be up to individual projects whether they take advantage of that or just continue with three per year. For example moving to quarterly releases would not be a big shift. The problem is that the current pattern is very engrained and our consumer community makes expectations of release periods far in advance. If we consider changing this we would need to give a lot of advance notice.

Another idea is that we already have a mechanism for doing releases every six weeks: the milestones. We could promote the milestones as the path for getting cutting edge new functionality on a faster rhythm. We could include the aggregate milestone repository URL starting with M1 so users can upgrade from milestone to milestone very easily. This is similar to what browsers do where they use the "beta channel" as the forum to get early testing and give early access to new function more quickly for those willing to live with a bit more instability. While this approach gives a channel to consume projects that release more frequently, the trade-off is that it also includes a lot of pre-release software that is not well validated. What people want is all the latest releases on a more frequent schedule... every month give me the latest version available of each project. In many cases it will be the same as last month but this is fine.

The release train and RT

We had a long general discussion about EclipseRT and its relationship to the release train. It is not well served by the current release train. They often release on a more frequent schedule so three releases a year isn't enough. They don't necessarily care about the aggregate repository because their users install their software in other ways (except for provisioning a target platform in their IDE). Many of the release train guidelines are not applicable to some of these projects (accessibility, translation, etc). They often have very little need to integrate with other Eclipse projects so releasing at the same time isn't necessarily as important. Maybe this is fine and the answer is that they just don't participate. This does mean they lose out on the marketing opportunity and focus that comes with being in the June release.

Could there be a completely separate EclipseRT release train. What would that look like? More frequent schedule, perhaps coordinated push of artifacts to maven central rather than p2.

Orbit

There was some discussion of the future of Orbit. We all agreed Wayne should take it over, but then Wayne arrived to the meeting and that plan was scrapped. The "bundle recipes" approach sounds promising. We could store only our custom metadata (Manifest.mf, etc) in the Orbit git repository. We would also need a persistent store of the original upstream binaries in case those upstream projects disappear (especially for LTS). However there would be no need for these upstream binaries to be in any version control system.


Next Meeting

  • April 3, 2013, "First Wednesday" Meeting

Reference

Kepler Wiki page
Juno Wiki page
Planning Council/Indigo retrospective
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO