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.
Architecture Council/Meetings/March 16 2014 ECon F2F
< Architecture Council | Meetings
Revision as of 00:22, 17 March 2014 by John arthorne.ca.ibm.com (Talk | contribs)
Attendees
Cedric, Tom W, John A, Mike M, Wayne, Gunnar, Ian B, Marcel, Markus K, Jonas
Minutes
- Carry-over discussion from planning council
- Idea: 4 month release cycles, 3 milestones per release
- Remove maintenance stream
- Idea: have two streams: annual stream, continuous release stream
- Is there a rule against projects putting major new releases in service releases? Some projects are doing it already.
- Many consumers like the service release model because they wait for the first service release assuming it is more stable
- What does LTS line up around if there are three releases a year that are not distinguished from each other
- Should projects be required to sign builds
- Signing is technology specific, different answer for plain Java, OSGi, native, ...
- When installing into IDE we check signatures, but runtime verification is rarely used
- Not much value for projects that are not installed into the IDE
- Should Eclipse projects be required to have downloads on the Eclipse download server
- Project might only provide source and user builds it themselves
- There is currently no restriction on putting downloads in other places in addition to download.eclipse.org
- Is it sufficient to have a page on download.eclipse.org that tells users where the downloads are found
- Vendor neutrality - if external download server goes away it breaks consumers
- We need institutional freedom of action: If some external service goes away overnight, we must be able to pick up the project and keep it going elsewhere
- We need to go off and think about what resources other than source code and bugzilla that are of paramount importance to host at eclipse.org