Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] SimRel Naming


Comments below.

On 04.05.2018 10:43, Gunnar Wagenknecht wrote:

On May 4, 2018, at 09:22, Ed Merks <ed.merks@xxxxxxxxx> wrote:

If that asked for "Volunteers needed for 2018-09 Release Train Webinars!" that would seem fine to me.

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.

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 as well.
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.  :-(
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, GMF).

I think I'm now getting you point, though. You want to be the release train name to be inclusive to all *these* projects/products?
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.

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

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. :)
That's why I'd rather avoid the whole mess and see what comes out in the wash. 

So what about Development Tools or just DevTools or Tools? Yes, some of it are frameworks not tools. Sight.
Exactly, always the sigh at the end.  :-(

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.
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 than later...

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 URLs).
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!
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.
The names of Eclipse Projects (and of the Eclipse Project, sigh), is also not part of this Planning Council discussion.

Thoughts on this conclusion?

So if you think purely about 1 - would that be also the simultaneous release train name?

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

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 brand.

Not sure I'll like it. 

what about:
- d.e.o/releases/tools
- d.e.o/releases/devtools
- d.e.o/releases/idetools

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 by forcing it to serve up metadata for older stuff that's never actually installed or resolved.
or stick with:
- d.e.o/releases/photon
No, that should only ever contain the one release we produce in June!

The simplest most obvious thing to me would be to produce a new 4 times each year and make point at it.  Perhaps have to reference the most recent milestone simple repositories.  And perhaps 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 quarterly release...



Gunnar Wagenknecht

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

Back to the top