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 and closed {{bug||185146}} as wontfix.''

+

''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 185:

Line 185:

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".

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||327381}}.''

+

''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|327381}}.''

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.

Announcements

Indigo SR2

Juno Plan and Requirements

M3

Requirements

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

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

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.