| Re: [eclipse.org-architecture-council] Separating releaseartifactsfrom update policy |
It was raised.
By me.
feedback was to bring it architecture council, which I did ;)
/max
From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx<mailto:konstantin.komissarchik@xxxxxxxxxx>>
Date: Monday, November 30, 2015 at 11:46 AM
To: Doug Schaefer <dschaefer@xxxxxxx<mailto:dschaefer@xxxxxxx>>, Eclipse Architecture Council <eclipse.org-architecture-council@xxxxxxxxxxx<mailto:eclipse.org-architecture-council@xxxxxxxxxxx>>
Subject: RE: [eclipse.org-architecture-council] Separating releaseartifactsfrom update policyThis was proposed and nothing happened.
I was hoping that some of the architecture council members that are also planning council members would bring this to the planning council. That hasn’t happened. I will try to take it to the planning council myself.
It might be worth the time to understand why they didn’t. For me, I think we have better things to spend our limited resources on. We’re still trying to figure out how to do minor releases 4 times a year let alone worry about maintenance releases.
Doug.
- Konstantin
From: Doug Schaefer
Sent: Friday, November 27, 2015 7:24 AM
To: eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] Separating releaseartifactsfrom update policy+1 Which was my point on the call. This was proposed and nothing happened.
I don¹t see anything that¹s changed to break that cycle at this point.IMHO, getting updates to users trumps whatever concerns auto registering
create.Doug.
On 2015-11-27, 2:05 AM,
"eclipse.org-architecture-council-bounces@xxxxxxxxxxxeclipse.org-architecture-council-bounces@xxxxxxxxxxx on behalf of
Aleksandar Kurtakov" <eclipse.org-architecture-council-bounces@xxxxxxxxxxx<mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx>
on behalf of akurtako@xxxxxxxxxxakurtako@xxxxxxxxxx> wrote:Max, Konstantin,
I agree with you that in theory there are better solutions and probably
they wouldn't be much expensive to achieve in time. But in practice, the
only option we have now is autoregistering update sites. As soon as there
is another better and working now way, I would happily drop the
autoregistration from Linux Tools and others will probably do the same.Alexander Kurtakov
Red Hat Eclipse team----- Original Message -----
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 policyDitto.
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.
- Konstantin
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 policyI¹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 policyHere 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.htmlThe 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,
- Konstantin
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.org-architecture-council@xxxxxxxxxxxhttps://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@xxxxxxxxxxxhttps://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.
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-councilIMPORTANT: 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.
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-councilIMPORTANT: 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.
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-councilIMPORTANT: 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.