** '''Resolution:''' Looks like steps are good enough in the short term (plus {{bug|315073}} discussion. After e4 release, showcase the "feature instead of zip", then mail projects asking to do the same.

** '''Resolution:''' Looks like steps are good enough in the short term (plus {{bug|315073}} discussion. After e4 release, showcase the "feature instead of zip", then mail projects asking to do the same.

−

* {{bug|315210}} Make the AC mailing list open

+

* {{bug|315210}} '''Make the AC mailing list open'''

** Ed: One idea would be expecting all AC members to be registered on the cross-project list; don't make the AC list "yet another" mailing list

** Ed: One idea would be expecting all AC members to be registered on the cross-project list; don't make the AC list "yet another" mailing list

** Martin: Make AC list a moderated list? - typical answer would be "yes, good idea, please file a bug"

** Martin: Make AC list a moderated list? - typical answer would be "yes, good idea, please file a bug"

Line 110:

Line 110:

** Doug S: Can be considered closed - was mostly an April Fool's Joke

** Doug S: Can be considered closed - was mostly an April Fool's Joke

−

==== e4 - current state of affairs ====

+

=== e4 - current state of affairs ===

* Boris: Making progress, release date unchanged (last Wed in July)

* Boris: Making progress, release date unchanged (last Wed in July)

Line 120:

Line 120:

* Existing compatibility list - Boris: existing Wiki page with known problems. Could start such a page easily (Dan Rubel wanted to set that up)

* Existing compatibility list - Boris: existing Wiki page with known problems. Could start such a page easily (Dan Rubel wanted to set that up)

−

==== AC Breakfast Followup ====

+

=== AC Breakfast Followup ===

−

See [[Architecture Council/Meetings/March 25 Breakfast]]

+

See [[Architecture Council/Meetings/March 25 2010 Breakfast]]

* Martin: Follow-up action items from Eclipsecon Breakfast

* Martin: Follow-up action items from Eclipsecon Breakfast

Line 148:

Line 148:

** Point to the Must-do in the Portal

** Point to the Must-do in the Portal

−

==== IP Log ====

+

=== IP Log ===

* Wayne: Had been looking through lots of IP logs - there is a misconception, especially about contributions, what should be in there.

* Wayne: Had been looking through lots of IP logs - there is a misconception, especially about contributions, what should be in there.

Line 157:

Line 157:

*** People use stuff from the Platform... technically, if you depend directly on a lib distributed by the Platform, you ought to CQ it

*** People use stuff from the Platform... technically, if you depend directly on a lib distributed by the Platform, you ought to CQ it

*** Wayne: Direct Reference to a 3rd Party Library requires a CQ.

*** Wayne: Direct Reference to a 3rd Party Library requires a CQ.

−

*** Example: Ant - No need to CQ when depending on Platform API that uses Ant internally; but need a CQ if

+

*** Example: Ant - No need to CQ when depending on Platform API that uses Ant internally; but need a CQ if you're using the library directly (e.g. you have a Requires-Bundle or Import-Package statement for the library in your bundle manifest)

−

*** Most of us should have a CQ for JUnit!

+

*** Most of us should have a CQ for JUnit! ''wtb: but don't panic; if you don't have one right now, don't worry about it. We'll be reviewing the policy post-Helios''

Tom Schindl been working on a forward compatibility layer to allow people take e4 features and have it running on top of e3.x (eg provide injection when running a part run on 3.x - allows same code to run on e3.x and e4)

Looks neat, might be something to look at in e3.7

Existing compatibility list - Boris: existing Wiki page with known problems. Could start such a page easily (Dan Rubel wanted to set that up)

Wayne: Would like to take the discussion more Meta; knows that Nick became interested in Tycho

AC should be making recommendations to the Community

Nick considered Athena a stop-gap measure from the beginning

Dave C: Much interesting Technology is around ... but it's still a bit of a Jungle

Wayne: Each has it's advantages, there may not be "the" answer. Buckminster, Maven, ...

Ed: Reproducable Buckminster builds for everything in Modeling. Cloudsmith interested in Buckminster for Platform. Although it's a Helios Requirement, hardly anybody can reproduce other projects' builds

Antoine: AC to set up "specs" for what a build tool needs to be able to provide?

What could be next steps for coming up with recommendations?

Dave C: Start with a Requirements Doc.

Wayne: Put together a Build Summit?

Antoine: Just putting all those guys in the same room won't work.

Kim: People won't agree on build technology. Helios Build Reqs may be a first step.

Build Users to write the Requirements.

AI Antoine and Dave C to start the Requirements doc

API Tooling

Produce an API report for all of Helios

Chris already did one (blogged it)

Point to the Must-do in the Portal

IP Log

Wayne: Had been looking through lots of IP logs - there is a misconception, especially about contributions, what should be in there.

Any contribution that is in the current codebase must be in that codebase's log. Even if 4 years old.

The easiest way to do this is to put the iplog+ flag on the attachment.

Don't iplog+ whole bugzilla's

Ed: If I use some other project, and that other project uses libraries: When I'm using them, I ought to file a CQ for using these

People use stuff from the Platform... technically, if you depend directly on a lib distributed by the Platform, you ought to CQ it

Wayne: Direct Reference to a 3rd Party Library requires a CQ.

Example: Ant - No need to CQ when depending on Platform API that uses Ant internally; but need a CQ if you're using the library directly (e.g. you have a Requires-Bundle or Import-Package statement for the library in your bundle manifest)

Most of us should have a CQ for JUnit! wtb: but don't panic; if you don't have one right now, don't worry about it. We'll be reviewing the policy post-Helios