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
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