Jump to: navigation, search

Difference between revisions of "Planning Council/November 09 2011"

(Requirements)
(. 4 new items, all marked (currently) with "[added 10/18/2011]")
Line 174: Line 174:
 
A. Source build. (this turned out to be wordier than I'd like ... suggestions welcome ... is it worth having?)  
 
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. I removed the item, but added a few words about "all the source" to the build item. I wouldn't expect this to change anyone's behavior, but at least it will retain some connection to that old bugzilla request in case someone needs it.''
+
''This seemed redundant to most, especially if we have the "make source easy to get from repository" item. I removed the 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.  
 
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.  
Line 190: Line 190:
 
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.  
 
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
+
''Ending up removing. Even though some projects and adopters use/need these, there was concern that not all builders (je.g. Tycho) could easily produce or consume them). It is counter to some people's view that there be only a few repos and while contents change, the repo location does not.''
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).''
+
  
 +
''It was said it was thought to be a "good idea" to produce these repos ... all the mature projects already do ... but a) we should we be concerned too much about simply documenting 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 Planning Council is not 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). So, unless ever needed by the release train itself, is unlikely to ever be required.''
  
 
==== Other requirements? ====
 
==== Other requirements? ====

Revision as of 16:19, 15 November 2011

Logistics

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

PMC (and Strategic) Reps
Chris Aniszczyk Technology (PMC)
John Arthorne Eclipse (PMC) Y
 ??  ?TPTP? (PMC) X
Mik Kersten Mylyn (ALM) PMC R
Brian Payton Datatools (PMC) Y
Doug Schaefer Tools (PMC) Y
Adrian Mos (Marc Dutoo) SOA (PMC) Y
Ed Merks Modeling (PMC)
Jesse McConnell Rt (PMC)
David Williams WTP (PMC) (appointed Chair) Y
Gary Xue Birt (PMC)
Strategic Reps
Cedric Brun OBEO (Strategic Developer)
Stefan Daume Cloudsmith Inc.(Strategic Developer)
Neil Hauge Oracle (Strategic Developer) Y
Kaloyan Raev SAP AG (Strategic Developer) Y
Pascal Rapicault Sonatype (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer) R
Christian Kurzke Motorola (Strategic Developer)
Achim Loerke BREDEX (Strategic Developer) Y
(PMC rep) Actuate (Strategic Developer) X
(PMC rep) IBM (Strategic Developer) X
Appointed
Wayne Beaton Eclipse Foundation (appointed) Y
Inactive
[no name] CA Inc. (Strategic Consumer) X

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

Announcements

  • Any?

Congratulations on a great EclipseCon Europe!

Indigo SR2

  • Anything?

Nothing

Juno Plan and Requirements

M3

  • Any issues?

none

Requirements

Review Requirements for substance and wording. In particular:

An overall suggestion was to add summary at top with links to "new this year" items

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.

Suggestions:

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" ... plus add deadlines to headings.
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

. 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. I removed the item and closed bug comment 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.

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 comment 327381.


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.

Ending up removing. Even though some projects and adopters use/need these, there was concern that not all builders (je.g. Tycho) could easily produce or consume them). It is counter to some people's view that there be only a few repos and while contents change, the repo location does not.

It was said it was thought to be a "good idea" to produce these repos ... all the mature projects already do ... but a) we should we be concerned too much about simply documenting 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 Planning Council is not 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). So, unless ever needed by the release train itself, is unlikely to ever be required.

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.

A. SimRel/Simultaneous_Release_Requirements#Unit_Tests

dup

B. SimRel/Simultaneous_Release_Requirements#Compatibility_with_Previous_Releases

no time to discuss

Other clarifications?

no time to discuss existing requirements to see if improvement can be made

  • Comments after the meeting: The following notes were posted to planning list after meeting, which I copy here, to capture more easily with other items discussed, and document the "conclusion" or if other discussion needed.

... the list of 40+ "requirements" is pretty daunting for new projects coming to the train (even if half of them are optional). I think we should take any opportunity we can to cut this down or combine entries. I read through the document this morning and the following came to mind:

1) There are five items about localization: "Message Bundles", "Support Translations", "Excel in NL Support", "Test Localization" and "Enable Use With All Languages". We could probably combine these into a single "Localization" bullet point that contains all the details. We can leave it alone if people think it is helpful but I think having the information in one place would streamline it. Some of the specific technology choices will really vary across projects anyway.

Good idea I grouped them under a common heading for now, but left as separate items. We can discuss if a paragraph would be better ... but ... somehow they seem like "separate activities" to me. I would like to keep the "NL Translation" items separate from the "NL Enablement" since I think the later effects nearly everyone (even runtimes) whereas the former would not be applicable to any projects with no UI ... if there are any.

2) Retention Policy - this could just be a sentence on the "Provide p2 repository" entry.

Not sure ... are p2 repositories the only thing we retain? I know we in webtools say a lot more than that, see WTP Retention Policy.

3) Metrics. Do projects really do this? Is it just part of the release review documentation? One option here is just to submit your git repository to http://ohloh.net and let it produce your project stats. dash.eclipse.org, and Wayne's fancy new project pages also provide some stats.

Gone. (I once had high hopes of doing more here ... but, with nothing concrete, it is merely a good idea).


4) Optimization. I'm not really sure what this means. It just provides a link to a list of available p2 ant tasks. The "Provide p2 repository" entry already says repositories need to be conditioned and packed. What other optimization does this refer to?

Good point, I removed as an "items" but did move a form of the sentence to the p2 repository section.

Checklist (aka tracker)

Investigate if checklist can be improved and who can do it.

Did not have time to discuss

Other business

Any discussion or suggestions of "delegation policy".

It was agreed it was a "good idea" to state the policy (and allow delegation).

Next Meeting

  • December 7, 2011 (our regular "first Wednesday" meeting, at Noon Eastern).

Reference

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