On 04.05.2018 10:43, Gunnar Wagenknecht
If that asked for "Volunteers needed for
2018-09 Release Train Webinars!" that would seem fine to
Which one? Jakarta? IDE? Science?
Assuming we did coordinate such things, there would be just one.
:-P But that's up in the air. I think at this point there is no
actual point of confusion.
If that's what they want. They might want to call it the Eclipse
Jakarta Train. Who knows what they'll want to call that. But note
that we have enough trouble herding all the cats involved in the
current process, so adding several new herds of cats isn't going to
make that any easier, especially when we need to name/brand each
heard, and try not to overwhelm each herd with details that might
well not be significant to all herds. E.g., we just cross-projects
a lot, but clearly that's grown to be a herd of herds. :-(
Just because we mostly see only one today doesn't mean
others see the same. Yes, there is no Jakarta one yet, but I
bet there will be one coming and from a Foundation perspective
it would be great to re-use the "release train" term for that
It's one of the key success factors that the Foundation can
use when pitching for OS projects.
Is an RCP application a Desktop IDE? Is any
old IApplication a Desktop IDE? Must we include Desktop
in the qualifier in order to exclude something? Are we
not following branding guidelines because "Eclipse" is
missing from the name ? Is it still under qualified
because Eclipse has another Desktop IDE? And even if it
doesn't currently, will we need to change it when
Eclipse does have another one?
FWIW, I see IApplication as a technical term that should
not be confused with a product brand. Eclipse RCP also exists
as it's own product brand. It's a very good example that
something can co-exist while participating in the IDE release
train. This also applies to a lot others (eg., xText, EMF,
Well, certainly not named and branded to be exclusive of them, yes.
People out there build interesting runtime applications from things
like EMF and CDO and they can get all coordinated versions of all
this into their target platform from the train URL.
I think I'm now getting you point, though. You want to be
the release train name to be inclusive to all *these*
Yes, of course that's the main understanding, but in actual fact the
train URL is a good place to pick up a broad range of dependencies
when building applications.
Hmm... I was too much focused on the IDE because it *is*
the main product that is being shipped, i.e. I see people
assume Oxygen, Photon, etc. with being the IDE and
plugins/tools/products around it but not a synonym for RCP,
EMF, GEF, etc. You are right that with that in mind IDE might
be too narrow.
That's why I'd rather avoid the whole mess and see what comes out in
Naming things is hard. That's why I suggested in the past
to bring in a branding expert. I'm an engineer. I can name
variables (sometimes) but not products. :)
Exactly, always the sigh at the end. :-(
So what about Development Tools or just DevTools or
Tools? Yes, some of it are frameworks not tools. Sight.
Yes, I'd really like to see such a list of "here are the places we
need a name". E.g., we needed URLs in in the wiki sooner rather
The discussion over "the name" has gone on
forever and I still keep wondering (and asking), to what
specifically are we assigning a name? In that light, I
have to ask myself, what are the results of the release
train process itself?
+1 sometimes it helps breaking things down.
A segment in a URL is not a brand. :P It's clear from Board
discussions that URLs are not part of the discussion about naming
and branding. That doesn't mean we want crappy ones of course!
Part of my "too narrow IDE focus" is caused by combining 1
with 2+3. I think 2+3 must have IDE in it's brand name (and
The names of Eclipse Projects (and of the Eclipse Project, sigh), is
also not part of this Planning Council discussion.
I can also imagine that EPP can be renamed to "Eclipse IDE
Packaging Project". But the conclusion I think is that 2+3 is a
separate discussion from 1.
I've seen several proposals so far. But now we start getting into
really technical details about which repos are composites and which
are simple and what will be the URL for the new simple repo that's
produced 4 times each year? Note that we already have
Thoughts on this conclusion?
So if you think purely about 1 - would that be also the
simultaneous release train name?
That's a composite with a single child that should always reference
the simple repository with the latest release (in my opinion).
The next release could a simple repository in
Or perhaps in
But what the simrel buys us I'm not sure? And again, a URL is not a
No. Somewhere there needs to be a new simple repo 4 times each
year. And please for goodness sake let's not create giant growing
composites that are pretty much worse than useless because the serve
mostly the kill download.eclipse.org by forcing it to serve up
metadata for older stuff that's never actually installed or
Not sure I'll like it.
No, that should only ever contain the one release we produce in
or stick with:
The simplest most obvious thing to me would be to produce a new
http://download.eclipse.org/releases/YYYY-MM 4 times each year and
make http://download.eclipse.org/releases/latest point at it.
Perhaps have http://download.eclipse.org/releases/milestones to
reference the most recent milestone simple repositories. And
perhaps http://download.eclipse.org/releases/milestomes/latest as a
composite to reference the most recent milestone simple repository.
Clearly the Planning Council does need a plan for where the URLs
would be, with thought toward such horrible events as shipping a
release with a major bug that needs remediation before the next
eclipse.org-planning-council mailing list
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.