Difference between revisions of "Planning Council/November 09 2011"
|Line 140:||Line 140:|
== Indigo SR2 ==
== Indigo SR2 ==
== Juno Plan and Requirements ==
== Juno Plan and Requirements ==
Revision as of 14:55, 9 November 2011
|Meeting Title:||Planning Council Conference Call|
|Date & Time:||Wednesday, November 09, 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 we have not heard from in a year or so, 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
X = not expected
Congratulations on a great EclipseCon Europe!
Juno Plan and Requirements
- Any issues?
Review Requirements for substance and wording. In particular:
I. The three new major headings. Do they make it clear some are A. "normal" requirements (just needed earlier), B. some are required items to be in common repo, and C. some are essentially optional, though considered required for good adoption.
- In first one, "...but early" sounds vague, can it be reworded? More concrete?
- May be hard, since two of the 4 are LOTS earlier (M4), and two of them are 2 to 4 weeks earlier than usual
- Maybe just say "... but earlier than usual"
- In third one, "... (but optional)" sounds too optional (like, don't even read this section). Will leave out of heading and clarify in first paragraph
II. 4 new items, all marked (currently) with "[added 10/18/2011]"
A. Source build. (this turned out to be wordier than I'd like ... suggestions welcome ... is it worth having?)
This seemed redundant to most, especially if we have the "make source easy to get from repository" item
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.
General agreement that most projects don't specify anything in this part of "standard plan", but should, but exactly what they specify is up to them and their community of users and adopters (which I think is fairly clear in current write-up, but will clarify).
Some parts of it are a little wordy, such as doesn't need to be a tutorial on effects of changing Java levels. Will shorten/simplify it. (Some concern the document as a whole is getting too long ... both looks like a lot, and takes a long time to read.
C. Getting source from repositories. I'd like to make it "required" to use Eclipse-SourceReference, but there was some discussion on cross-project list that not everyone liked that idea. 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".
Needs work. 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 .
D. Provide archived p2 repositories. Again, I personally think this should be "required", but am not positive how many other projects do this already (I know many many do), and can not say for sure we would use them in the aggregation builds for Juno, so not sure it should be "required" this year ... but, it would go a long way towards having "reproducible aggregation builds". Plus, my speculative guess is, something like archived repos might be required for Eclipse LTS (Long Term Support), both to have something to depend on to re-create some packages, but more so, to be sure there is a concrete deliverable from a build against which future builds could be compared.
Needs work. Again needs clearer purpose. Concern it is counter to some models (that is, in effect, you end up with lots of little repos, possibly located all over, instead of one or a few big repos that contain everything needed to build against. Some builders, (I think Tycho was mentioned) do not currently, natively provide this support. It was said it is a "good idea" to produce these repos ... but a) should we be concerned about good ideas and b) we do not know what the LTS solution is so unclear we can justify it for that reason. (Not to mention, the PC nor planning council is directly responsible for LTS, so while ok to make things easier if/when needed, there is no reason to jump the gun, were some views discussed).
III. Other requirements?
- I added 2 more "new" ones, marked with [11/09/2011]. We won't "settle" these today, since obviously no time to review completely with PMCs, members, etc., but hope to introduce them and discuss a little.
no time to discuss
IV. Other clarifications?
no time to discuss existing requirements to see if improvement can be made
Checklist (aka tracker)
Investigate if checklist can be improved and who can do it.
Any discussion or suggestions of "delegation policy".
It was agreed it was a "good idea" to state the policy (and allow delegation).
- December 7, 2011 (our regular "first Wednesday" meeting, at Noon Eastern).