Notice: This Wiki is now read only and edits are no longer 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"
(→Members and Attendees) |
|||
| Line 116: | 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> | ||
| − | == | + | == 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. | |
| − | + | == 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. | ||
| + | |||
| + | |||
| + | Build reproducibility. Many projects contribute a composite repository and their aggregator contribution never changes. | ||
| + | This means builds are not reproducible. If you respin later you might pick up new content. This makes it very difficult | ||
| + | to do emergency respins, there is no way to diff the inputs and see what has changed. b3 aggregation files are brittle, | ||
| + | if there was an easier way to update your contribution would projects do it more frequently. Do we require that | ||
| + | projects contribute only concrete repositories? Another solution is having consistent repository structure across | ||
| + | all projects. For example eclipse.org/projectName/milestones/m1 projectName/releases/kepler... | ||
| − | |||
*Agenda topics (mentioned in previous meeting, feel free to add) | *Agenda topics (mentioned in previous meeting, feel free to add) | ||
Revision as of 22:11, 25 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
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.
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.
Build reproducibility. Many projects contribute a composite repository and their aggregator contribution never changes.
This means builds are not reproducible. If you respin later you might pick up new content. This makes it very difficult
to do emergency respins, there is no way to diff the inputs and see what has changed. b3 aggregation files are brittle,
if there was an easier way to update your contribution would projects do it more frequently. Do we require that
projects contribute only concrete repositories? Another solution is having consistent repository structure across
all projects. For example eclipse.org/projectName/milestones/m1 projectName/releases/kepler...
- Agenda topics (mentioned in previous meeting, feel free to add)
- Decide SR Policy.
- Should Rt have their own "repo"? Their own Sim Rel Rules? How can the value to them be increased?
- What relationship is there (should there be) between OSGi/p2 common repo and Maven/Maven Repos?
Next Meeting
- April 3, 2013, "First Wednesday" Meeting