[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eclipse.org-architecture-council] Re: Next Year's Release Train to require being "e4 ready"?
- From: Mike Wilson <Mike_Wilson@xxxxxxxxxx>
- Date: Wed, 16 Dec 2009 10:16:06 -0500
- Delivered-to: email@example.com
The message is still "The Eclipse 4.0 SDK will run all API clean 3.x plug-ins.". To my mind, it wouldn't make sense to consider putting it on the release otherwise. So, the "e4 readiness" point is basically API-cleanliness + testing.
David M Williams ---2009/12/15 22:28:22---Its great to see this advance, forward thinking.
David M Williams <david_williams@xxxxxxxxxx>
[eclipse.org-architecture-council] Re: Next Year's Release Train to require being "e4 ready"?
Its great to see this advance, forward thinking.
We have discussed briefly at Planning Council meetings and so far the reaction of Projects has been "no plans to anything for e4" but, I'm sure, that's mostly because most of us simply need education on what it buys us and what we'd have to do to get it.
But most importantly, I would hope most of this would be a "bottoms up" requirement and implementation, where projects found reason to be on e4, and/or implement some advanced function that could only be done with e4. And if widespread, then we'd naturally want that commonality codified for the 2011 Simultaneous Release. Remember, "we are us" when it comes to the Planning Council and the requirements for Simultaneous Release ... we require very little that is not already fairly common.
But it is an excellent point we should all begin to educate ourselves on the implications, and work with our "home Projects" to understand how to take advantage of e4.
I'd urge care on the message, "e4 ready". One message I've heard is "e4 is completely compatible, projects need not do anything to run on e4". I don't know the latest, and don't know if that will always be true, but, we don't want to mistakenly give the wrong impression to the community that "... it will take some work to get ready for e4" (unless that is the current message). And I think a message like "2011 release will be based on e4" raises the question in Projects of a.) what will that take, and b.) what do we get for it. I'm not sure those can be answered before EclipseCon, but would be good to start the discussion, so I will put it on Planning Council agenda.
And, yes, I think a 2 hour joint session on Sunday is a good idea.
|From: ||"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> |
|To: ||David M Williams/Raleigh/IBM@IBMUS, <donald.smith@xxxxxxxxxxx> |
|Cc: ||"eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx> |
|Date: ||12/15/2009 01:47 PM |
|Subject: ||Next Year's Release Train to require being "e4 ready"?|
In last week's Architecture Council call, we discussed the current state of affairs regarding
e4. We concluded that in order for e4 to gain momentum, it will be extremely important to
make the wider Community aware... and for Eclipse Projects to start becoming "e4 ready".
All this is still quite some time away, but we figured that the marketing buzz around releasing
Helios would be a great time to make an announcement that is very widely heard. If we
could announce at that time that next year's release train is going to be "e4 ready" if not
"based on e4", that would help a lot.
Could you start seeding that idea in the Planning Council... what the PC members think
about potentially making "e4 readiness" or "testing against e4" a must-have for next
year's train? What people think about promoting the EPP Packages to build against /
deliver on top of e4?
What would be a good avenue for "feeding back" the PC's thoughts into the AC?
BTW, planning for a joint PC and AC (==StAC?) face-to-face session at EclipseCon 2010
seems like a good idea... who could schedule this?
eclipse.org-architecture-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.