Re: [eclipse.org-architecture-council] Separating release artifactsfrom

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

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/msg02606.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.