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.
Planning Council/November 23 2011
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, November 23, 2011, at 1200 Eastern |
| Dial-in: | For the call-in numbers, see the "Project Review" number on Foundation Portal page. |
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
Requirements
Review Requirements for substance and wording.
In brief, the things to focus on, for this "off cycle" meeting, are the proposed changes for Juno Release.
See last meeting notes from November 09, 2011 for detailed notes of previous discussion. But, below is a brief summary of what we talked about last time and actions taken.
This meeting was not well attended, due to holidays and conflicting meetings, so some issues may come back up at our next meeting, but at this meeting there was general agreement with substance of the plan, edits made so far, and that "Getting source from repositories" is worth keeping (in semi-optional, ease adoption category), if wording can be improved and agreed upon.
The three new major headings.
- Changed headings based on feed back from last meeting.
4 (now 2) proposed new items, all marked (currently) with "[added 10/18/2011]"
A. Source build.
- I removed the proposed new item and closed bug 185146 as wontfix.
B. Target Environments (Platforms and Java Levels). I tried to add some general advice, to especially help new projects, but no substantial "new work" ... just to encourage teams to think through and document what they support.
- I simplified the wording.
C. Getting source from repositories. I once thought it'd be nice to "require" the use Eclipse-SourceReference, but there was some discussion on cross-project list that not everyone liked that idea, for valid reasons. So, tried to word so that "its a good idea, and if you don't use Eclipse-SourceReference, you should provide some other easy way".
Need to discuss more? Need to clarify purpose. Is it to improve workflow, so contributors can easily provide patches? Is it so adopters IP staff can get a copy of all source used in a build? Or, both? Larger question is if it is implementable. Currently there are no commonly used tools to created team project sets (though, there are ant scripts around that do it, such as Orbit). Currently, an Eclipse-SourceReference for GIT is not implemented and no clear commitment to do it, despite being a regression in available functionality, see bug 327381.
D. Provide archived p2 repositories.
- Removed the proposed new item. Not enough agreement it was required to mention, though often good idea, many already do provide, and seemed counter to one popular builder. PLUS, we (Planning Council) have always resisted in the past doing anything to "make builds better or easier" (as it was not actually our mission), instead, focusing simply on what makes it easier for users to install things, and improve consumability by adopters. So, bad idea to include for many reasons (though, still a good idea to do).
Other requirements?
- no time to discuss at previous meeting. Its already "required" as part of standard plan ... but, I think some guidance/mention in this document helps clarify expectations for Simultaneous Release. Any objections? Suggestions?
Other clarifications?
- Comments/actions after the meeting based on John's note to planning list ... see last meeting notes for detailed notes.
- I incorporated most, but not all suggestions, so further discussion welcome.
- I did some more "grouping" of like-items ...
- grouped several under "Excel in NL support" heading, as suggested by John
- moved 3 items up under "plan"
- moved several under a "bundle form and format" heading
- moved 2 API related items together under "APIs" (net effect was to move one "required" item to "optional" sections ... but, was basically about documenting things, anyway ... nothing "concrete" to (easily) test for common repo.
- In addition to removing the "metrics" item, I propose we remove the "capabilities" item
- Other comments/improvements to plan?
Checklist (aka tracker)
Investigate if checklist can be improved and who can do it.
Possible solutions:
- correct Portal, to be accurate to current list (and correct some minor issues, such as in some cases two fields for data were included, when one would have sufficed).
- After that's done the summary PHP pages would need to be fixed to match the Portal data.
- medium budget fix: request "XML file" (similar in concept to "standard plan") that would have and specified schema, with standard headings, etc., and then someone could write XSL/XQuery scripts to roll-up results. In theory, someone could write a form-like "front end" to produce the XML files.
- low budget fix: provide a template (or, example) wiki page, that would consist of headings only ... that projects could copy and fill out for their project. In this approach there would be no "roll up".
Good discussion around this issue. While no good solution is in sight for Juno, some tactical plans made.
Achim and Wayne have discussed the first (high budget) item, and Wayne said that there are not resources in Foundation to do either (neither they themselves fix, nor for them to do the work to allow someone else to work on "Eclipse Foundation code" to fix).
The second "medium budget" item was deemed too expensive, too much work, and not fitting in with long term approach of having super-portal that would "do it all".
Tactical solution was to a) disconnect current code and summaries, leaving only the 'simultaneousrelease' field (and its summary page) but to remove the rest; b) provide a wiki page "template" (not official wiki template) and tell projects if they wanted their own checklist or summary they could make a copy of that, and fill it in, as they go; c) will require projects in Simultaneous Release to have a section where they state "Have complied with Simultaneous Release requirements, and have listed any exceptions below".
Longer term, not in time for Juno, fields such as link to rampdown plan, link to accessibility testing, link to API policy, retention policy, etc. will be part of the new "super portal" for projects to fill in, or not, depending on type of release, needs of the project, etc.
Some of the discussion here pointed out that there is a fundamental conflict here, which we must be careful to not lose sight of, and explicitly keep balanced: on the one hand we want things to be as easy as possible for projects to "release" and for committers not to have to do one bit of anything that is "extra work". On the other hand, the Simultaneous Release is expected to be held to a higher standard than a normal, ordinary project release; more work is expected for those wishing to voluntarily participate, especially with regards for providing a solid foundation for (strategic member) adoption. The pendulum swings ... if participation is too hard, projects will not voluntary participate, if expectations are too low, strategic members will lose interest and not see or get any value. Thus, important to always discuss from both points of view.
To document reasons for the checklists and summary pages:
- Projects have asked for it, in the past; to have a short summary to follow, to guide them along, especially new projects.
- It was intended as a way for Project leads and PMCs and Planning Council to check progress towards compliance.
- It was intended as an easy way for adopters to get quick, overall information about a project. For example, if a project had no retention policy and did not do any work towards accessibility, then an adopter might decide it was not suitable to include in their commercial product. Without such a summary, there is risk it will be more work for everyone (clearly for adopters, trying to find out that information) but also for projects, if they get asked the same questions frequently. Similarly, a project might be "overlooked" for adoption because there is no information easily available with this important data.
Other business
- Are we failing in our mission, if common repo (as a whole) is not able to be mirrored?
- See bug 362734
- Off hand, quick comments were "mirroring is hard, there's many complications, methods, ins and outs, and probably beyond our scope or mission to worry too much about ... its more about the tools to allow and do the mirror and resolve issues." In general, I think it is a problem that two, perfectly consistent repositories, might not be consistent when taken in composite ... but ... agree its a problem that is not the Planning Council's concern (unless ... someone comes up with a specific reason our process causes it).
- Anything else?
Next Meeting
- December 7, 2011 (our regular "first Wednesday" meeting, at Noon Eastern).