Re: [eclipse.org-architecture-council] Sep 10 Meeting Notes

[Eike Stepper <stepper@xxxxxxxxxx>]

Am 10.09.2015 um 18:39 schrieb Konstantin Komissarchik:

From my perspective…

 

The problem that Max brought up of projects auto-registering their update sites is very valid. Separating release artifacts from the update policy would allow multiple update streams to co-exists at Eclipse Foundation and in the commercial world.

 

However, before we can label the practice of auto-registering project update sites as bad, we need to have a better answer for how projects can deliver out-of-cycle updates without having users go out of their way looking for those updates, as most will not. So here is my concrete proposal for the Planning Council to consider:

 

Start with the current simrel process. On top of that, allow projects to have an update site added to the simrel composite for that year, such as the Mars composite. The burden is on the project to test compatibility. If a project contributes a release in this manner

Are you really meaning a release? With a release review and the full process?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

and a cross-project issue crops up, once the issue is validated, the project’s repository is immediately dropped from the composite, thus returning us to a known good state. Then it’s up to the project to rectify the issue with a new release before being re-added. In some cases, it might mean that the project has to wait for another project to update first or work with them at our designated coordinated release points.

 

This would effectively formalize what’s already happening through auto-registering of update site URLs. The difference is that we would have a formalized process on what happens when things go wrong and by making auto-registration unnecessary, we would make creating other release vehicles with different update policies easier (getting back to Max’s concern), whether those come from Eclipse Foundation or from third parties.

 

Thanks,

 

- Konstantin

 

 

From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Thursday, September 10, 2015 9:17 AM
To: eclipse.org-architecture-council@xxxxxxxxxxx
Subject: [eclipse.org-architecture-council] Sep 10 Meeting Notes

 

Hi all,

 

Notes of today’s meeting are now online:

https://wiki.eclipse.org/Architecture_Council/Meetings/September_10_2015

 

A lively discussion about making it easier to provide “important updates” to Eclipse users (off Stream Updates).

Doug agreed taking the discussion to the Planning Council, but we could also continue exchanging ideas on the Mailing List.

 

Next meeting is planned for Oct.8, please put agenda items on the Wiki.

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6

 

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.