Skip to main content

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.

Jump to: navigation, search

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

(4 (now 2) proposed new items, all marked (currently) with "[added 10/18/2011]")
(4 (now 2) proposed new items, all marked (currently) with "[added 10/18/2011]")
Line 164: Line 164:
 
A. Source build.  
 
A. Source build.  
  
* I removed the proposed new item and closed {{bug||185146}} as wontfix.
+
* 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.  
 
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 172: Line 172:
 
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".  
 
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}}.''
+
''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.  
 
D. Provide archived p2 repositories.  

Revision as of 11:24, 16 November 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

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


Requirements

Review Requirements for substance and wording.

See last meeting notes for detailed notes.

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

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, and seemed counter to one popular builder. PLUS, we (Planning Council) have always resisted in the past doing anything to "make builds better/easier" (as "not our job"), instead, focusing simply on what makes it easier for Users to install things, and improve consumability by adopters. So, bad idea for many reasons.

Other requirements?

  • no time to discuss at last 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 [[Planning_Council/November_09_2011| 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 ...
moved 3 items up under "plan"
moved several under a "bundle form and format" heading
in addition to "Excel in NL support" heading
  • 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.

Other business

  • Any?

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

Back to the top