[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] Sep 10 Meeting Notes
|
All sounds good. But any enforcment or similar should be put ***only after*** the new way of doing things with automated tools to check/validate/etc. are in production use. Any try to enforce something without another working and better solution is doomed to create more damage than help.
Alexander Kurtakov
Red Hat Eclipse team
----- Original Message -----
> From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
> To: "eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
> Sent: Thursday, 10 September, 2015 10:34:33 PM
> Subject: Re: [eclipse.org-architecture-council] Sep 10 Meeting Notes
>
>
>
> This could be at least partly enforced outside of simrel by doing the check
> as part of the release review. I agree that we’d need a tool to automate the
> check, either way.
>
>
>
> - Konstantin
>
>
>
>
>
>
> From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
> [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of
> Doug Schaefer
> Sent: Thursday, September 10, 2015 12:28 PM
> To: eclipse.org-architecture-council
> Subject: Re: [eclipse.org-architecture-council] Sep 10 Meeting Notes
>
>
>
>
>
> The problem is that outside the simrel release, it’s unenforceable. Inside
> the simrel, the only hammer we have is to exclude projects from the simrel.
> Plus we’d have to create the tooling to check to see whether violations have
> occurred. We don’t have the manpower to do this manually.
>
>
>
>
>
> 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, September 10, 2015 at 1:28 PM
> To: Eclipse Architecture Council <
> eclipse.org-architecture-council@xxxxxxxxxxx >
> Subject: Re: [eclipse.org-architecture-council] Sep 10 Meeting Notes
>
>
>
>
>
>
>
>
> I am generally of the same mind, but note that the problem that Max brought
> up is not limited to projects on Simrel. A project may not be part of
> Simrel, yet still interfere with adopter’s ability to control the update
> policy.
>
>
>
> - Konstantin
>
>
>
>
> From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [
> mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx ] On Behalf Of
> Eike Stepper
> Sent: Thursday, September 10, 2015 10:17 AM
> To: eclipse.org-architecture-council
> Subject: Re: [eclipse.org-architecture-council] Sep 10 Meeting Notes
>
>
>
>
>
> Am 10.09.2015 um 19:00 schrieb Konstantin Komissarchik:
>
>
>
>
> > As for the current practice of projects auto-registering their sites
>
> > (which as you mention becomes unnecessary), do you think we
>
> > should outlaw this practice in our formal release guidelines, or should
>
> > we simply encourage projects to use this new process?
>
>
>
> I think we should outlaw the practice in EDP, not just in Simrel,
>
> I generally don't like the idea of putting more regulations on projects
> outside of the release train.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>
>
>
>
> once we have provided other alternatives. My reasoning on this is that this
> gets in adopter’s way of controlling their update policy, which is a
> violation of one of key principles that projects provide a good re-usable
> foundation for others to build on.
>
>
>
> - Konstantin
>
>
>
>
>
>
> From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [
> mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx ] On Behalf Of
> Ian Bull
> Sent: Thursday, September 10, 2015 9:54 AM
> To: eclipse.org-architecture-council
> Subject: Re: [eclipse.org-architecture-council] Sep 10 Meeting Notes
>
>
>
>
>
> Konstantin,
>
>
>
>
>
> I like this proposal because it 1) solves the problem that Max brought up, 2)
> brings some sanity to the problem of projects adding update sites and 3) is
> actionable.
>
>
>
>
>
> As for the current practice of projects auto-registering their sites (which
> as you mention becomes unnecessary), do you think we should outlaw this
> practice in our formal release guidelines, or should we simply encourage
> projects to use this new process?
>
>
>
>
>
> Cheers,
>
>
> Ian
>
>
>
>
>
> On Thu, Sep 10, 2015 at 9:39 AM, Konstantin Komissarchik <
> konstantin.komissarchik@xxxxxxxxxx > wrote:
>
>
> From my perspective…
>
>
>
> 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.
>
>
>
> Thanks,
>
>
>
> - Konstantin
>
>
>
>
>
>
> From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:
> eclipse.org-architecture-council-bounces@xxxxxxxxxxx ] On Behalf Of
> Oberhuber, Martin
> Sent: Thursday, September 10, 2015 9:17 AM
> To: eclipse.org-architecture-council@xxxxxxxxxxx
> Subject: [eclipse.org-architecture-council] Sep 10 Meeting Notes
>
>
>
>
> 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
>
>
>
>
>
> _______________________________________________
> 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.
>
>
>
>
>
>
>
>
>
> --
>
>
> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
> http://eclipsesource.com | http://twitter.com/eclipsesource
>
>
>
>
>
>
> _______________________________________________
> 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.
