*** Wayne: Just move to Archive makes it still available but not mirrored

+

** '''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'''

+

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

+

** Mostly a psychological matter .. make us APPEAR more open. Boris agrees.

+

** '''AI Martin''' follow up with Eclipse IT to make it happen. Moderators - Martin, Kim, Andrew

* 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)

*** 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''

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