|
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
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?
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
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.
--
_______________________________________________
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.
|
