Architecture Council/Meetings/August 11 2016
|Meeting Title:||Architecture Council Monthly Meeting|
|Date & Time:|| Thursday August 11, 2016 at 1100 Ottawa |
HTML | iCal
|Dial-in:|| Let's use the Foundation's Asterisk setup for this call:
Participant conference extension: 701 then enter pin: 51968
- 1 Agenda / Notes
- 2 Attendees
- 3 Next Meeting
Agenda / Notes
- Feel free to edit, but not during the call!
- Last meeting: Architecture Council/Meetings/June 9 2016 -- open actions see #Action_Items
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 firstname.lastname@example.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 ?
- Put this data on bug 499399
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 ?
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
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.
|Eclipse:||Dani Megert|| |
|Tools:||Doug Schaefer|| |
- In attendance: Wayne Beaton, Jonas Helming, Dani Megert, Martin O, Doug Schaefer, Michael Scharf