Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Architecture Council/Meetings/March 16 2014 ECon F2F

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

Back to the top