- 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@xxxxxxxxxxx on behalf of
Aleksandar Kurtakov" <eclipse.org-architecture-council-bounces@xxxxxxxxxxx
on behalf of akurtako@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>
>> To: "eclipse.org-architecture-council"
>><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.
>>
>> * 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 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@xxxxxxxxxxx on behalf of
>> Konstantin Komissarchik konstantin.komissarchik@xxxxxxxxxx
>> Reply-To: Eclipse Architecture Council
>> eclipse.org-architecture-council@xxxxxxxxxxx
>> Date: Thursday, November 12, 2015 at 12:28 PM
>> To: Eclipse Architecture Council
>>eclipse.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,
>>
>> - Konstantin
>>
>>
>>
>>
>>
>> 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.
>>
>> /max
>> http://about.me/maxandersen
>>
>> _______________________________________________
>> 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.
>_______________________________________________
>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.
_______________________________________________
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.
