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 "Architecture Council/Meetings/August 11 2016"

(Wayne: Changes to IP Policy)
 
(4 intermediate revisions by one other user not shown)
Line 26: Line 26:
 
* Last meeting: [[Architecture Council/Meetings/June 9 2016]] -- open actions see [[#Action_Items]]
 
* Last meeting: [[Architecture Council/Meetings/June 9 2016]] -- open actions see [[#Action_Items]]
  
* Tyler Jewell '''EDP and distributing via Docker images'''
+
=== Jonas: {{Bug|499399}} Eclipse Infrastructure - Uptime and speed ===
* Jonas Helming Eclipse Infrastructure - Uptime and speed https://bugs.eclipse.org/bugs/show_bug.cgi?id=499399
+
* Not meant as an offence, but there is a general perception (from clients) that the Eclipse.org infra is unstable
 +
** Build servers, Gerrit, Wiki, Eclipsecon.org ... even PUBLIC services like Eclipsecon.org were very slow and then down for 2 days !
 +
** Why is Eclipsecon.org run internally and not on the Cloud ?
 +
** No suggestion for a solution, but the perception causes harm to the Community !
 +
** Some people already moved away, or are considering to go away ("...have to wait 3 days until a build is done...")
 +
** Just a perception or is it a real problem (around uptime and speed) ?
 +
** Is the infra too complex to host with a given budget ?
  
<!--
+
* Dani: Agrees with the perception - issues started some time last year, already raised on the Board meeting
=== New Topics ===
+
** Please point to specific issues seen, if possible ... would like to stick to Eclipse.org, others might be worse in respect to response time
  
=== General Topics ===
+
* Wayne: Please CC webmaster@eclipse.org on the bug
 +
** What are the core services that need to be at Eclipse.org, which others could be offloaded ?
 +
** For example, some projects want to use 3rd party services, which can't be hosted at Eclipse.org anyways
 +
** Webmaster been playing with Cloud services managed by the Eclipse Foundation (though surveys indicate hosting ourselves is more cost effective ... but then can't dynamically scale up)
 +
** Maybe we're at a crossing point where Cloud should be considered for some services at least
  
* '''New AC Member candidates''' - see [[Architecture Council/Members and Mentors]], and the [http://www.eclipse.org/org/foundation/council.php#architecture Councils Page]
+
* Doug: In general happy with how things are going, just noticed some issues around the yearly release
** Tyler Jewell representing strategic member CodeEnvy
+
** Eclipse Che vs. Platform discussion
+
* '''Eclipse Infrastructure''' - git, Gerrit, Maven, Hudson, Bugzilla, ...
+
* '''Updates from the Board or the EMO'''
+
  
== Action Items  ==
+
* '''ACTION:''' Please collect data on issues / outages that led to a bad perception ?
 +
* '''ACTION:''' What services need to be on Eclipse.org , which services could reasonably be outside ?
 +
** Put this data on {{bug|499399}}
  
*No new action items.
+
=== Tyler Jewell: EDP and distributing via Docker images ===
*Cleaned up old action items, see [[Architecture Council/Meetings/February 10 2011]] for old stuff
+
* Wayne: Most projects produce some sort of a download to be consumed ("traditional model")
*(''old'') '''Tim''' write up an initial wiki page with information for people to standardize on the tracing API
+
* This doesn't make much sense for Che - Docker makes much more sense there ("docker run eclipse/che")
*(''old'') '''Martin''' revise the AC Wiki to make it easier to find the New Member Process. More links on homepage. More usage of categories.
+
** Wayne secured the "eclipse" organization on dockerhub, investigating how to manage that with the Community
*(''old'') '''Martin''' {{bug|315210}} Make the AC mailing list open / moderated
+
** Already connected with the Mosquito project for input
 +
** Docker had some changes recently (Windows vs Linux etc) now pushing forward
  
-->
+
* What does this mean with respect to the IP policy ?
 +
** It does make sense for Che to be consumable via docker for easy consumption
 +
** For consumers building their customized projects, it still makes sense for Docker to be "buildable" and to maintain an IP Log
 +
** Martin: Not so much concerned about the mechanics of downloads ... more concerned about the meaning of "exempt pre-req" (related to docker pre-req?) as well as download scanning software which checks downloads against the IP Log
 +
** Maybe if consumers are happy with whatever comes from dockerhub, it doesn't make sense for the EF to place additional constraints / restrictions
 +
 
 +
=== Wayne: Changes to IP Policy ===
 +
EF is working on a change to the IP Policy as [https://mmilinkov.wordpress.com/2016/06/29/overhauling-ip-management-at-the-eclipse-foundation/ blogged by Mike recently]
 +
* Introducing a new, lighter-weight type of due diligence (license check on contained code only - no provenance)
 +
** Only check what a project "claims" for Type A releases, but not check if it's actually true
 +
* Projects could choose to be "Type A" or "Type B" per release
 +
** Expecting that Vertex would move to Type A ... others to do some releases Type A, and at some point do Type B
 +
** Sounds very similar to "parallel IP process" -- '''how to mark up what is what? How to deal with aggregates as being Type A or Type B ?'''
 +
** Wayne: <strike>Mature projects couldn't be Type B - only for Incubating ones. Helps them work out which software / licenses they actually need.</strike>
 +
 
 +
Wayne's follow up:
 +
<blockquote>The phase of the project (e.g. incubation, mature) is separate from the type of IP due diligence used in any particular release.
 +
 
 +
I did suggest a couple of scenarios...
 +
 
 +
* A project starts with Type A and stays with Type A for its entire lifespan
 +
* A project starts with Type A and changes to Type B when it graduates
 +
* A project does multiple releases with Type A and a periodic release with Type B.
 +
 
 +
The point is that the project can decide what level of due diligence to bring for a release.
 +
 
 +
I also suggested that this will likely result in the IP team doing due diligence on what the project demonstrates they actually need as they get closer to the release with Type B, rather than what they think they need the beginning of a release cycle like we do today.
 +
 
 +
FWIW, I find it easier to think about this as a has-a relationship, i.e. a particular release has a type of IP due diligence rather than a particular release is a Type A release.
 +
 
 +
I still think that the blood type analogy works really well and am disappointed at the lack of uptake.
 +
 
 +
There's more discussion on {{Bug|496959}}, including a suggestion to use  "license compatible" and "known provenance" labels.</blockquote>
 +
 
 +
* Jonas: Has there been any survey on what Eclipse.org consumers actually want ?
 +
** There's a feeling that Eclipse.org actually does more than most companies do ... consumers like that, but is it actually necessary ? For example if node.js is used...
 +
 
 +
=== Wayne: New AC Members ===
 +
* '''ACTION''' Wayne propose candidate
 +
 
 +
=== Martin: UUID / Call Home Policy ===
 +
* Got in touch with Ian Skerret: No current plans on resurrecting UUID / data gathering. If there ever is, Ian would reach out to the AC.
 +
* Jonas: Any conclusion on cleaning up existing UUIDs ?
 +
** Currently not discussed as an issue, since UUIDs were only generated in milestone builds.  Feel free to reopen if this is considered an issue.
 +
 
 +
=== Wayne: Inactive Projects ===
 +
* Projects that are not actively maintained but still considered useful
 +
** RSE, some modeling projects, ...
 +
** Discussion on {{bug|}}
 +
 
 +
* Projects that get funding initially, but stop when the funding ends - dysfunctional projects
 +
** Once funding returns, new committers restart - EDP has this as an exception, but not as a standard practice
 +
** This basically sacrifices meritocracy - how big of a deal is this ? Concerned about projects that lack continuity
 +
** Problem if EF has to constantly teach the committers the process ... if they went to Github, they'd have a hard time handing the keys from one to the next
 +
** Discussion on {{bug|}}, answer might be we don't care
  
 
== Attendees  ==
 
== Attendees  ==
Line 59: Line 122:
 
|-
 
|-
 
| '''BIRT:'''  
 
| '''BIRT:'''  
| Wenfeng Li
+
| <strike>Wenfeng Li</strike>
| Wenbin He
+
| <strike>Wenbin He</strike>
 
|-
 
|-
 
| '''DTP:'''  
 
| '''DTP:'''  
| Brian Payton
+
| <strike>Brian Payton</strike>
| Linda Chan
+
| <strike>Linda Chan</strike>
 
|-
 
|-
 
| '''Eclipse:'''  
 
| '''Eclipse:'''  
 
| Dani Megert
 
| Dani Megert
| Mike Wilson
+
| <strike>Mike Wilson</strike>
 
|-
 
|-
 
| '''Modeling:'''  
 
| '''Modeling:'''  
| Ed Merks
+
| <strike>Ed Merks</strike>
| Cédric Brun<br>Eike Stepper
+
| <strike>Cédric Brun<br>Eike Stepper</strike>
 
|-
 
|-
 
| '''Mylyn:'''  
 
| '''Mylyn:'''  
| Steffen Pingel
+
| <strike>Steffen Pingel</strike>
| Mik Kersten
+
| <strike>Mik Kersten</strike>
 
|-
 
|-
 
| '''RT:'''  
 
| '''RT:'''  
| Christian Campo
+
| <strike>Christian Campo</strike>
| Tom Watson<br>Doug Clarke<br>Ian Bull
+
| <strike>Tom Watson<br>Doug Clarke<br>Ian Bull</strike>
 
|-
 
|-
 
| '''SOA:'''  
 
| '''SOA:'''  
| Adrian Mos
+
| <strike>Adrian Mos</strike>
| Marc Dutoo
+
| <strike>Marc Dutoo</strike>
 
|-
 
|-
 
| '''Technology:'''  
 
| '''Technology:'''  
| Gunnar Wagenknecht
+
| <strike>Gunnar Wagenknecht</strike>
 
| Wayne Beaton
 
| Wayne Beaton
 
|-
 
|-
Line 95: Line 158:
 
|-
 
|-
 
| '''WTP:'''  
 
| '''WTP:'''  
| Chuck Bridgham
+
| <strike>Chuck Bridgham</strike>
| Neil Hauge
+
| <strike>Neil Hauge</strike>
 
|-
 
|-
 
| '''LocationTech:'''
 
| '''LocationTech:'''
| Jim Hughes
+
| <strike>Jim Hughes</strike>
 
|
 
|
 
|-
 
|-
 
| '''IoT:'''
 
| '''IoT:'''
| Julien Vermillard
+
| <strike>Julien Vermillard</strike>
 
|
 
|
 
|}
 
|}
Line 111: Line 174:
  
 
* '''Regrets:'''  
 
* '''Regrets:'''  
 +
 +
* '''In attendance:''' Wayne Beaton, Jonas Helming, Dani Megert, Martin O, Doug Schaefer, Michael Scharf
  
 
<!--
 
<!--

Latest revision as of 12:01, 15 August 2016

Meeting Title: Architecture Council Monthly Meeting
Date & Time: Thursday August 11, 2016 at 1100 Ottawa
Html.gifHTML | Ical.gifiCal
Dial-in: Let's use the Foundation's Asterisk setup for this call:
  • North America (toll free) 1-866-569-4992
  • Germany (local call anywhere in Germany) 49-692-2224-6059
  • France (local call anywhere in France) 33-17-070-8535
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
  • Spain, Sweden, others - see Asterisk/Numbers

Participant conference extension: 701 then enter pin: 51968

  • SIP clients can call 701@asterisk.eclipse.org, then enter pin 51968.

Agenda / Notes

Jonas: bug 499399 Eclipse Infrastructure - Uptime and speed

  • Not meant as an offence, but there is a general perception (from clients) that the Eclipse.org infra is unstable
    • Build servers, Gerrit, Wiki, Eclipsecon.org ... even PUBLIC services like Eclipsecon.org were very slow and then down for 2 days !
    • Why is Eclipsecon.org run internally and not on the Cloud ?
    • No suggestion for a solution, but the perception causes harm to the Community !
    • Some people already moved away, or are considering to go away ("...have to wait 3 days until a build is done...")
    • Just a perception or is it a real problem (around uptime and speed) ?
    • Is the infra too complex to host with a given budget ?
  • Dani: Agrees with the perception - issues started some time last year, already raised on the Board meeting
    • Please point to specific issues seen, if possible ... would like to stick to Eclipse.org, others might be worse in respect to response time
  • Wayne: Please CC webmaster@eclipse.org on the bug
    • What are the core services that need to be at Eclipse.org, which others could be offloaded ?
    • For example, some projects want to use 3rd party services, which can't be hosted at Eclipse.org anyways
    • Webmaster been playing with Cloud services managed by the Eclipse Foundation (though surveys indicate hosting ourselves is more cost effective ... but then can't dynamically scale up)
    • Maybe we're at a crossing point where Cloud should be considered for some services at least
  • Doug: In general happy with how things are going, just noticed some issues around the yearly release
  • ACTION: Please collect data on issues / outages that led to a bad perception ?
  • ACTION: What services need to be on Eclipse.org , which services could reasonably be outside ?

Tyler Jewell: EDP and distributing via Docker images

  • Wayne: Most projects produce some sort of a download to be consumed ("traditional model")
  • This doesn't make much sense for Che - Docker makes much more sense there ("docker run eclipse/che")
    • Wayne secured the "eclipse" organization on dockerhub, investigating how to manage that with the Community
    • Already connected with the Mosquito project for input
    • Docker had some changes recently (Windows vs Linux etc) now pushing forward
  • What does this mean with respect to the IP policy ?
    • It does make sense for Che to be consumable via docker for easy consumption
    • For consumers building their customized projects, it still makes sense for Docker to be "buildable" and to maintain an IP Log
    • Martin: Not so much concerned about the mechanics of downloads ... more concerned about the meaning of "exempt pre-req" (related to docker pre-req?) as well as download scanning software which checks downloads against the IP Log
    • Maybe if consumers are happy with whatever comes from dockerhub, it doesn't make sense for the EF to place additional constraints / restrictions

Wayne: Changes to IP Policy

EF is working on a change to the IP Policy as blogged by Mike recently

  • Introducing a new, lighter-weight type of due diligence (license check on contained code only - no provenance)
    • Only check what a project "claims" for Type A releases, but not check if it's actually true
  • Projects could choose to be "Type A" or "Type B" per release
    • Expecting that Vertex would move to Type A ... others to do some releases Type A, and at some point do Type B
    • Sounds very similar to "parallel IP process" -- how to mark up what is what? How to deal with aggregates as being Type A or Type B ?
    • Wayne: Mature projects couldn't be Type B - only for Incubating ones. Helps them work out which software / licenses they actually need.

Wayne's follow up:

The phase of the project (e.g. incubation, mature) is separate from the type of IP due diligence used in any particular release.

I did suggest a couple of scenarios...

  • A project starts with Type A and stays with Type A for its entire lifespan
  • A project starts with Type A and changes to Type B when it graduates
  • A project does multiple releases with Type A and a periodic release with Type B.

The point is that the project can decide what level of due diligence to bring for a release.

I also suggested that this will likely result in the IP team doing due diligence on what the project demonstrates they actually need as they get closer to the release with Type B, rather than what they think they need the beginning of a release cycle like we do today.

FWIW, I find it easier to think about this as a has-a relationship, i.e. a particular release has a type of IP due diligence rather than a particular release is a Type A release.

I still think that the blood type analogy works really well and am disappointed at the lack of uptake.

There's more discussion on bug 496959, including a suggestion to use "license compatible" and "known provenance" labels.
  • Jonas: Has there been any survey on what Eclipse.org consumers actually want ?
    • There's a feeling that Eclipse.org actually does more than most companies do ... consumers like that, but is it actually necessary ? For example if node.js is used...

Wayne: New AC Members

  • ACTION Wayne propose candidate

Martin: UUID / Call Home Policy

  • Got in touch with Ian Skerret: No current plans on resurrecting UUID / data gathering. If there ever is, Ian would reach out to the AC.
  • Jonas: Any conclusion on cleaning up existing UUIDs ?
    • Currently not discussed as an issue, since UUIDs were only generated in milestone builds. Feel free to reopen if this is considered an issue.

Wayne: Inactive Projects

  • Projects that are not actively maintained but still considered useful
    • RSE, some modeling projects, ...
    • Discussion on bug
  • Projects that get funding initially, but stop when the funding ends - dysfunctional projects
    • Once funding returns, new committers restart - EDP has this as an exception, but not as a standard practice
    • This basically sacrifices meritocracy - how big of a deal is this ? Concerned about projects that lack continuity
    • Problem if EF has to constantly teach the committers the process ... if they went to Github, they'd have a hard time handing the keys from one to the next
    • Discussion on bug , answer might be we don't care

Attendees

All AC Members are invited.

  • PMC Reps please confirm attendance or list your delegate below. Every PMC is required to name a primary and backup delegate, and to ensure that one delegate attends the meeting.
BIRT: Wenfeng Li Wenbin He
DTP: Brian Payton Linda Chan
Eclipse: Dani Megert Mike Wilson
Modeling: Ed Merks Cédric Brun
Eike Stepper
Mylyn: Steffen Pingel Mik Kersten
RT: Christian Campo Tom Watson
Doug Clarke
Ian Bull
SOA: Adrian Mos Marc Dutoo
Technology: Gunnar Wagenknecht Wayne Beaton
Tools: Doug Schaefer
WTP: Chuck Bridgham Neil Hauge
LocationTech: Jim Hughes
IoT: Julien Vermillard

All Attendees

  • Regrets:
  • In attendance: Wayne Beaton, Jonas Helming, Dani Megert, Martin O, Doug Schaefer, Michael Scharf


Next Meeting

Back to the top