Random thoughts:
Is validation (ensuring 'installablity') enough? Potential runtime problems can not be detected with current means easily and ClassNotFoundErrors, MethodNotFoundErrors, etc. made 12% of all error reports during Mars *Milestone* builds.
Two additional ideas to (build-time) validation:
Projects participating in such streams (stable/testing/unstable or stable/beta/developer/canary or however you wanna call them) should
1) use API baselines to ensure compiler compatibility, 2) should sign up for any runtime class loader issue reported e.g., by the automated error reporting.
2cts
Marcel
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.
_______________________________________________ eclipse.org-architecture-council mailing list eclipse.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@xxxxxxxxxxx to request removal.
-- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
|
