Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Planning Council/March 24 2013"
(draft agenda) |
m (→Members and Attendees) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 7: | Line 7: | ||
|- | |- | ||
| Date & Time: | | Date & Time: | ||
| − | | | + | | Sunday, March 24, 2013, at [http://www.timeanddate.com/worldclock/fixedtime.html?year=2013&month=03&day=24&hour=14&min=0&sec=0&p1=179 1400 Eastern] |
|- | |- | ||
| Face-to-Face. No Dial-in. | | Face-to-Face. No Dial-in. | ||
| Room: South End, on the Plaza Level (top floor) of the World Trade Center. <br />Note: MeetGreen will be at the venue setting up registration in case you need anything. | | Room: South End, on the Plaza Level (top floor) of the World Trade Center. <br />Note: MeetGreen will be at the venue setting up registration in case you need anything. | ||
|} | |} | ||
| − | |||
== Members and Attendees == | == Members and Attendees == | ||
| Line 24: | Line 23: | ||
| Chris Aniszczyk | | Chris Aniszczyk | ||
| Technology (PMC) | | Technology (PMC) | ||
| − | | | + | | No |
|- | |- | ||
| John Arthorne | | John Arthorne | ||
| Line 36: | Line 35: | ||
| Brian Payton | | Brian Payton | ||
| Datatools (PMC) | | Datatools (PMC) | ||
| − | | | + | | No (not attending EclipseCon) |
|- | |- | ||
| Doug Schaefer | | Doug Schaefer | ||
| Tools (PMC) | | Tools (PMC) | ||
| − | | | + | | Yes |
|- | |- | ||
| Adrian Mos | | Adrian Mos | ||
| Line 48: | Line 47: | ||
| Ed Merks | | Ed Merks | ||
| Modeling (PMC) | | Modeling (PMC) | ||
| − | | | + | | No |
|- | |- | ||
| Ian Bull | | Ian Bull | ||
| Line 56: | Line 55: | ||
| David Williams | | David Williams | ||
| WTP (PMC) (appointed Chair) | | WTP (PMC) (appointed Chair) | ||
| − | | No | + | | No. |
|- | |- | ||
| Gary Xue | | Gary Xue | ||
| Line 72: | Line 71: | ||
| Cedric Brun | | Cedric Brun | ||
| OBEO (Strategic Developer) | | OBEO (Strategic Developer) | ||
| − | | | + | | No |
|- | |- | ||
| Neil Hauge | | Neil Hauge | ||
| Line 81: | Line 80: | ||
| SAP AG (Strategic Developer) | | SAP AG (Strategic Developer) | ||
| No (not attending EclipseCon) | | No (not attending EclipseCon) | ||
| − | |||
| − | |||
| − | |||
| − | |||
|- | |- | ||
| Markus Knauer | | Markus Knauer | ||
| Line 94: | Line 89: | ||
| Yes | | Yes | ||
|- | |- | ||
| − | | | + | | Shawn Pearce |
| Google (Strategic Developer) | | Google (Strategic Developer) | ||
| − | | | + | | Yes |
|- | |- | ||
| (PMC rep) | | (PMC rep) | ||
| Line 121: | Line 116: | ||
<small>Note: feel free to correct any errors/omissions in above attendance record.</small><br/><small>Y = Yes, attended</small><br/><small>N = No, did not</small><br/><small>R = regrets sent ahead of time</small><br/><small>D = delegated</small><br/><small>X = not expected</small> | <small>Note: feel free to correct any errors/omissions in above attendance record.</small><br/><small>Y = Yes, attended</small><br/><small>N = No, did not</small><br/><small>R = regrets sent ahead of time</small><br/><small>D = delegated</small><br/><small>X = not expected</small> | ||
| − | == | + | == 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. | ||
Latest revision as of 16:40, 28 March 2013
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
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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