From: "Max Rydahl Andersen" <manderse@xxxxxxxxxx<mailto:manderse@xxxxxxxxxx>>
To: "eclipse.org-architecture-council"
<eclipse.org-architecture-council@xxxxxxxxxxx<mailto:eclipse.org-architecture-council@xxxxxxxxxxx>>
Sent: Friday, 27 November, 2015 6:29:10 AM
Subject: Re: [eclipse.org-architecture-council] Separating release
artifactsfrom update policy
Ditto.
Any updatesite that uses this mechanism is basically not usable for
reuse.
By setting up a separate mechanism to introduce project updates hidden
from
behind a composite
things are much more manageable and CDT etc. still get to release nice
updates.
For me that is a win-win situation.
/max
Doug,
I understand where you are coming from. We do need to facilitate
projects in
delivering updates in a more timely fashion. But I do think that
auto-registering project¹s update site is wrong solution for the
problem.
When a project auto-registers an update site, they are asserting
control over
the update policy in all contexts the project¹s artifacts are used. No
matter how well-intentioned, projects are going to get this wrong for
some
contexts. On top of that, projects will not agree on what kind of
updates
are appropriate to push in this manner and we have a mess instead of a
clean
update story.
From: Doug Schaefer
Sent: Thursday, November 12, 2015 10:24 AM
To: eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] Separating release
artifactsfrom update policy
I¹ll restate my concern about this. Because the p2 update site for my
Arduino
C++ IDE is registered when my users install it from the Marketplace,
they
can use Check for Updates to get the fixes I do for them. Because it¹s
my p2
site, I can fix bugs and get it to them in a matter of minutes.
I want to be able to do that with the entire CDT. And I personally
recommend
all projects set up to do that. And I don¹t want to have to burden
anyone to
get that done. And right now, auto registering my update site, and I
mean
update, not feature, is the best way to accomplish that.
Doug.
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxxeclipse.org-architecture-council-bounces@xxxxxxxxxxx on behalf of
Konstantin Komissarchik konstantin.komissarchik@xxxxxxxxxxkonstantin.komissarchik@xxxxxxxxxx
Reply-To: Eclipse Architecture Council
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.org-architecture-council@xxxxxxxxxxx
Date: Thursday, November 12, 2015 at 12:28 PM
To: Eclipse Architecture Council
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.org-architecture-council@xxxxxxxxxxx
Subject: [eclipse.org-architecture-council] Separating release
artifacts from
update policy
Here is my message from September with a concrete plan for enabling
projects
to deliver updates more frequently to simrel consumers, thus opening
the way
for AC to recommend that projects do not register update sites through
their
p2 repositories.
This intersects the domains of architecture and planning councils.
https://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/ms
g02606.html
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 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.
[new text] The implementation cost of this proposal is that we either
need to
open up access to the composite to all project leads to add update
repositories and remove them if a cross-project issue is reported or we
need
someone tasked with this. If the composite is in Git, so it¹s easy to
revert
changes, if necessary, my preference is for a decentralized approach.
Thanks,
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.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@xxxxxxxxxxxemo@xxxxxxxxxxx to request removal.
/max
http://about.me/maxandersen
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.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@xxxxxxxxxxxemo@xxxxxxxxxxx to request removal.
