Bugzilla – Full Text Bug Listing
| Summary: | Replace Platform Classic/SDK with EPP Classic/SDK including EGit | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Markus Knauer <mknauer> | ||||
| Component: | committers-package | Assignee: | Martin Oberhuber <mober.at+eclipse> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | bugs.eclipse.org, daniel_megert, david_williams, ian.skerrett, irbull, john.arthorne, Lars.Vogel, loskutov, Mike_Wilson, mjmeijer, mknauer, mober.at+eclipse, overholt, reckord, sptaszkiewicz, wayne.beaton | ||||
| Version: | 2.0.0 | ||||||
| Target Milestone: | 2.0.0 M6 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 375292, 404165, 408859, 408866 | ||||||
| Attachments: |
|
||||||
|
Description
Markus Knauer
Cross referencing... * Eclipse PMC meeting minutes - the topic had been discussed there: December 19, 2012 http://wiki.eclipse.org/Eclipse/PMC/Minutes_2012 * bug 359466 - Remove CVS from Eclipse SDK package So... I think we're aligned on what needs to be done technical, the only question is who can do it ? What is involved in creating an EPP Classic/SDK package, how much effort is it, who could step forward and do it ? Why is this package better than "Eclipse for RCP and RAP Developers"? I think it's a perception thing. People are used to "Eclipse Classic" so that's what they download. Just look at the download statistics (can't find them right now). Maybe package contents also plays some role but I don't think so. Technically, we could probably just remove "Eclipse Classic" from the main download pages and tell people to use RCP/RAP instead and see what happens. Giving them something that is similar to Classic but includes egit is the nicer approach though. We are all pretty strained for resources. Adding another package that provides very similar content to a package that already exists seems a little silly in that context. However minimal, any new package will require at least some resources to keep up-to-date and test. It will also take up valuable disk and mirror space. Lots of it. (In reply to comment #5) > We are all pretty strained for resources. Adding another package that > provides very similar content to a package that already exists seems a > little silly in that context. However minimal, any new package will require > at least some resources to keep up-to-date and test. It will also take up > valuable disk and mirror space. Lots of it. I agree with Wayne and Martin. I guess most people just download(ed) 'Classic' out of old habits. Maybe we can either make the Classic, a.k.a. as Eclipse SDK, download a less prominent or even remove it entirely as suggested by Martin. We could place a comment where to find it and also mention that there are pure downloads (Platform, RCP) for people that want to start with a minimal install and then add whatever they like (e.g. Git, Git, CVS, etc.). Also note, there are still lots of other companies and people who still use CVS or SVN to develop their Eclipse-based software. During all our past discussions in the PMC (last one last December, see http://wiki.eclipse.org/Eclipse/PMC/Minutes_2012), we always concluded that the Eclipse top-level project does not want to start adding any other Team provider(s) and that we will keep building, supporting and shipping CVS as part of our SDK. The Eclipse packages are the means to offer software bundles to our community. So, if there is really the need for a 'Classic' download that has CVS replaced with Git, then this would be up to the EPP project and to someone who steps forward and maintains it (e.g. package testers). +1 with Dani But I should also mention, that to a large extent this is also a self-hosting discussion. Eclipse.org uses git for its repositories. There should be a single preferred base package for developing plugins for the Platform which is hosted at Eclipse.org . So this is a Platform discussion just as much as it is a Community discussion. The RCP/RAP package today IMO caters to end users today. Maybe it could be re-used as the preferred selfhosting package. At least it should be clearly specified as such. (In reply to comment #2) > What is involved in creating an EPP Classic/SDK package, how much effort is > it, who could step forward and do it ? Every EPP package needs a maintainer who is responsible for defining the content, responsible for test-and-sign-off. This maintainer will become committer in EPP and should be someone from the Platform team. I would offer to provide an initial version if the Eclipse PMC decides that this package is required. (In reply to comment #3) > Why is this package better than "Eclipse for RCP and RAP Developers"? Good question. Some will say there's no advantage, but for others there may be reasons such as - it's smaller, compacter - it contains only JDT/PDE (but not Mylyn, Code Recommenders, XML Editors, RAP Tools, WindowBuilder, Marketplace Client, ...) (In reply to comment #7) > The RCP/RAP package today IMO caters to end users today. Maybe it could be > re-used as the preferred selfhosting package. At least it should be clearly > specified as such. In that case I'd like to invite people from the Platform team to help me improve the RCP/RAP package. (In reply to comment #8) > (In reply to comment #2) > > What is involved in creating an EPP Classic/SDK package, how much effort is > > it, who could step forward and do it ? > > Every EPP package needs a maintainer who is responsible for defining the > content, responsible for test-and-sign-off. This maintainer will become > committer in EPP and should be someone from the Platform team. I would offer > to provide an initial version if the Eclipse PMC decides that this package > is required. > > (In reply to comment #3) > > Why is this package better than "Eclipse for RCP and RAP Developers"? > > Good question. Some will say there's no advantage, but for others there may > be reasons such as > - it's smaller, compacter > - it contains only JDT/PDE (but not Mylyn, Code Recommenders, XML Editors, > RAP Tools, WindowBuilder, Marketplace Client, ...) In that case, they could even start with Eclipse Platform (SDK or Runtime) which is also free of CVS, JDT and PDE. As of Juno SR2, these are the exact differences between Classic and RCP/RAP: - Only in Eclipse Classic (182MB): cvs.source, help.source, jdt.source, pde.source - Only in Eclipse for RCP/RAP (227MB, thats +25%): egit, mpc, m2eclipse, mylyn, recommenders, windowbuilder, rap.tools, xmledit Advanced eclipse.ini with -XX:MaxPermSize=256m, lucene.tokenizer, openFile I'm not sure if the "compactness" of a download is really still that relevant these days. From my personal experience, the various additional plugins in rcp/rap are very non-intrusive so they don't hurt much when not used. Relevance of the .source packages is also reduced with being able to provision .source through egit any time; I must say I'm starting to sympathize with just replacing Eclipse Classic on the download page with a "please use Eclipse for RCP/RAP instead" notice... I'm in the process of stopping to use the RCP/RAP download in my Eclipse RCP trainings because https://bugs.eclipse.org/bugs/show_bug.cgi?id=383802 is really annoying for the new RCP developers. The title says "replace Platform Classic /SDK, with EPP Classic/SDK". Are we just talking about on the EPP downloads page, or are we talking about not providing the standard SDK anymore. Martin outlined the differences between the bundles included in the Classic SDK and the RAP/RCP EPP Package (thanks Martin). However, there is a bigger difference, the build schedule. The Classic SDK is built weekly (well, nightly, but that's not really intended for consumption). Many people rely on this build. If we are going to "replace" the classic with an EPP Package, will this new package be available on a weekly basis? (In reply to comment #12) > The title says "replace Platform Classic /SDK, with EPP Classic/SDK". Are we > just talking about on the EPP downloads page, or are we talking about not > providing the standard SDK anymore. > > Martin outlined the differences between the bundles included in the Classic > SDK and the RAP/RCP EPP Package (thanks Martin). However, there is a bigger > difference, the build schedule. The Classic SDK is built weekly (well, > nightly, but that's not really intended for consumption). Many people rely > on this build. If we are going to "replace" the classic with an EPP Package, > will this new package be available on a weekly basis? The idea was that the new "Classic EPP" package would take the place of the Eclipse SDK *on the main download page*. The Eclipse SDK in its current form would still be produced on its current schedule, but would only appear on the Eclipse project download page. (In reply to comment #12) > The Classic SDK is built weekly (well, nightly, > but that's not really intended for consumption). Many people rely on this build. > If we are going to "replace" the classic with an EPP Package, will this new > package be available on a weekly basis? Having recently moved from Hudson 2.x to 3.0.0 from eclipse.org, I was pleasantly surprised by the auto configure wizard that appeared on first launch. This eases ramp-up very much. I know that Eclipse has the welcome pages for what is actually installed, and Marketplace for the "all you can eat" cliemnts, but maybe something else is needed as well: A sort of first launch wizard that allows you to add a selection of essential bundles: EGit, maybe Mylyn/bugzilla, and a pointer to marketplace. Maybe its just a "Further Configuration" Cheat sheet. (In reply to comment #8) I would like to revive this discussion that appears to be somewhat stalled. First of all, some clarifications: 1. The goal of this work is making the "Eclipse Classic" package which is available from EPP downloads, relevant again as "the minimal selfhosting package" now that Eclipse has moved to git and is moving to Tycho. 2. We would replace the Platform-Built Classic SDK on the eclipse.org download pages by the new EPP-built Classic SDK so there shouldn't be any change in net data volume. 3. Package contents shall be the current Eclipse Classic SDK contents + egit + marketplace client as a new selfhosting minimum. I'd like to add mpc as the "trampoline" for adding more stuff. I don't know whether adding m2eclipse is necessary or relevant now that Platform is moving to CBI / Tycho; personally I'd rather not add it but comments are welcome here. We want to keep CVS in the package to avoid any community disruption. 4. The value of the package compared to RCP/RAP is that it would contain all the Platform team's sources for reference, but it would be smaller in terms of the tools provided and thus hopefully more stable and easier to learn (no mylyn, recommenders, xmleditors, windowbuilder, rap.tools). Adding contents through *.p2f import or Marketplace is always easier than removing contents. With the package described that way, does anybody have any concerns against production of the package, then please speak up now. Regarding the next steps: > (In reply to comment #2) > Every EPP package needs a maintainer who is responsible for defining the > content, responsible for test-and-sign-off. This maintainer will become > committer in EPP and should be someone from the Platform team. What is the expected effort for "test-and-sign-off" given that only egit and mpc are added beyond plain Platform ? Would it suffice to simply use it myself as a developer for a day to perform my daily tasks close to release ? > I would offer to provide an initial version if the Eclipse PMC decides > that this package is required. Thanks a lot Markus ! I guess we're going to take that offer :) > Why is this package better than "Eclipse for RCP and RAP Developers"? As per above: Smaller, more compact, easier to learn, has all sources. And, we avoid bug 383802 because rap.tools is not included. Does this sound like a plan that we can embark on ? (In reply to comment #10) > I'm not sure if the "compactness" of a download is really still that > relevant these days. From my personal experience, the various additional > plugins in rcp/rap are very non-intrusive so they don't hurt much when not > used. That's not entirely true. For example, try debugging certain performance bug having all those additional plugins added. You can't disable all the additional jobs that are spawned from additional plugins. It is no longer that easy then. (In reply to comment #15) > 1. The goal of this work is making the "Eclipse Classic" package which is > available from EPP downloads, relevant again as "the minimal selfhosting > package" now that Eclipse has moved to git and is moving to Tycho. In the Eclipse 3.x world, the Eclipse Classic download was sufficient. Now, in the Eclipse 4.x reality we have Git as repository, xtext, ecore, genmodel files in Platform UI, POM files everywhere and possibly many other dedicated files that I am not aware of. Self-hosting means not only ability to download source code but also ability to develop the whole Platform using the out-of-the-box download package. > 3. Package contents shall be the current Eclipse Classic SDK contents > + egit > + marketplace client > as a new selfhosting minimum. I'd like to add mpc as the "trampoline" > for adding more stuff. I don't know whether adding m2eclipse is > necessary or relevant now that Platform is moving to CBI / Tycho; > personally I'd rather not add it but comments are welcome here. We want > to keep CVS in the package to avoid any community disruption. From my point of view, the new recommended download for Eclipse Platform development should be: - minimal but "complete" - support "self-hosting" I put complete and self-hosting in quotation marks because it is not defined what it actually should mean. If we want to add EGit then why not other plugins for example for editing ecore files? Marketplace Client doesn't look like a complete necessity since it not needed for completeness and definitely not for self-hosting. My 2 cents... (In reply to comment #16) > I put complete and self-hosting in quotation marks because it is not defined > what it actually should mean. If we want to add EGit then why not other > plugins for example for editing ecore files? Marketplace Client doesn't look > like a complete necessity since it not needed for completeness and > definitely not for self-hosting. I propose adding the marketplace client exactly in order to offer a compromise between "minimal" and "complete" : It allows providing a minimal base but still making it very easy to add things as needed. That being said, there's other workflows for adding things (p2 import wizard from *.p2f files for instance), and MPC does in fact add some intrusion (I think it registers an URL listener and even adds an org.eclipse.ui.startup extension). To me, the MPC intrusion seems acceptable compared to the value one gets; but if we agree that *.p2f files (or some other mechanism) are the way to go for extending the base, that's fine. I think though that some mechanism for extending the base must be in. Regarding the editing of .ecore and xtext files : My thought was that Eclipse Classic should stay as close to the original Classic as possible in order to remain "minimal". The goal would be to enable simple bug fixes with the minimal Classic only. The workflow would be 1. Plugins View, Add All to Java Search (to enable source-level debug) 2. Start self-hosted debug session 3. Identify location of issue (with PDE Plugin Spy, or kill -3 thread dump) 4. Import plugin to edit (Plugins view, egit import from repo) 5. Make change and submit patch to gerrit. In my understanding, editing of .ecore and xtext files goes beyond simple bugfixes, and whoever needs to do that would likely import the "e4 tools" package via a *.p2f extension file. Similar for pom.xml changes, that's likely something a "simple contributor" would usually not do. So, my proposal still stands making the new Classic be Classic + egit + mpc. I'll keep this bug open for a bit more discussion, but I'd like the new package to be available for M6 / EclipseCon so we should find some agreement for the first iteration at least (which doesn't need to be the final iteration). We discussed this on the Eclipse PMC today [1], and we would like to move forward with the proposal, so:
* Markus, can you please create an initial "EPP Classic" Package, that contains
- Eclipse Classic SDK as of today + egit + marketplace client
* I can sign up as the tester initially (going to look for someone else later)
- Please let me know what's the expectations for testing the package
* Anything else that's needed at this point ?
One question that came up was, how frequently could the package be produced based on the latest Platform's I-build p2 repo ? If it is possible to produce the EPP daily or so, testing would be much easier; leading up to each milestone, the Platform team does a test pass anyways, so one (or some) of the developers could simply use the new EPP Classic package for that.
But the pre-requisite for this is having the EPP package available 1 week before the milestone, that is at "-7" time in simrel terminology. It's not a blocker if that is not possible, but it would be nice.
[1] http://wiki.eclipse.org/Eclipse/PMC March 13 Notes
(In reply to comment #18) > We discussed this on the Eclipse PMC today [1], and we would like to move > forward with the proposal. Glad to hear this! I'll keep that in mind when I start working on the packages for the next milestone... I hope to do this as soon as the platform milestone release is out, probably at the weekend. My goal is to have this available before EclipseCon. (In reply to comment #19) Thanks Markus ! Perhaps one other step you could do right away is initiate a committer election for myself to the epp project, since I would be the initial maintainer ? Thanks Martin (In reply to comment #18) > * Markus, can you please create an initial "EPP Classic" Package, that > contains > - Eclipse Classic SDK as of today + egit + marketplace client I've done that part now. There are now two new projects in the Git repository http://git.eclipse.org/c/epp/org.eclipse.epp.packages.git/ (packages/org.eclipse.epp.package.classic and packages/org.eclipse.epp.package.classic.feature). These projects will be the basis for further adjustments. (In reply to comment #20) > Perhaps one other step you could do right away is initiate a committer > election for myself to the epp project, since I would be the initial > maintainer ? Done. Committer election process has been started. (In reply to comment #18) > One question that came up was, how frequently could the package be produced > based on the latest Platform's I-build p2 repo ? If it is possible to > produce the EPP daily or so, testing would be much easier; leading up to > each milestone, the Platform team does a test pass anyways, so one (or some) > of the developers could simply use the new EPP Classic package for that. That's a new requirement for the EPP project, but I am sure that we can find a solution for this one. Maybe we need to setup additional build jobs on Hudson that are using a different set of p2 repositories for this build and are triggered by updates in these p2 repositories. I'd suggest to start with what we have and adjust things as required after EclipseCon (but in time before M7). The benefits of the Classic SDK with regard to feature set/download size have been discussed here at length. And it's true that as a user, one reason for me to make the Classic SDK my download of choice is that it contains the minimum of bundles that I'd need anyway and nothing more. I'd just like to add one thing: There's a second, even more important reason for me to choose the SDK over other bundles - the fact that it comes with source bundles. I'm aware of the source provisioning through EGit and Eclipse-SourceReferences. But that doesn't give me out-of-the-box source navigation on error log entries and such. I always make a point of installing SDK or source bundles for everything (i.e. Mylyn SDK instead of Mylyn, Egit + Egit Source etc.) and so far the Classic SDK has been the best starting point for that. In that vein, I'm excited to get EGit and MPC with my download of choice, but I would be even more excited if their source bundles were included, too. (In reply to comment #22) > In that vein, I'm excited to get EGit and MPC with my download of choice, > but I would be even more excited if their source bundles were included, too. The Eclipse for RCP/RAP Developers comes with source bundles. (In reply to comment #23) > The Eclipse for RCP/RAP Developers comes with source bundles. Great. Wasn't aware of that. Thanks for the clarification. But taking a quick peek, it seems to be for the platform only. Sources for JDT, PDE, CVS found in the SDK as well as for all bundles added by RCP/RAP are not included, which was my point. Including source bundle is always a difficult decision. E.g. my own opinion is even stricter: I wouldn't include source bundles in any package. It makes the packages bigger and they don't help anyone who uses a proper defined target that is independent from the IDE. I would prefer to educate people more in that direction, but I know how hard it is (because it is so easy to use your IDE as a compile target). In case of the SDK/Classic package my hope is that we can reduce the source bundles to a bare minimum. +1 for source bundles. Leaving them out, will make access to Eclipse harder, as we want more contributor we should avoid that. Thanks Markus - I'm downloading a first package from Kepler nightly right now: http://build.eclipse.org/technology/epp/epp_build/kepler/download/20130316-1738/ Could you please also add the "classic-package" component on Bugzilla for tracking issues ? Regarding the source bundles, we can discuss more modern ways of provisioning sources as we move forward; I will discuss this with the Eclipse PMC. IMO the technical advantages of source bundles included are (1) I can debug everything self-hosted immediately, (2) for archival of old packages I have the sources of what I look at, and (3) it works in secured labs with limited Internet access. Maybe a good solution to satisfy everyone would be splitting the package downloads in two parts, where part 1 has the binary bits and part 2 has the sources. Then sources are "downloadable" but every downloader could choose whether to get sources or not. Extracting both ZIP's into the same location would combine the two parts again (not sure if that works with p2, maybe dropins would have to be used). For the initial builds (M6), I would like to get exactly the same content as the original classic had (change one thing at a time only). That is, adding sources for the org.eclipse.cvs and org.eclipse.help features too. We can leave out the sources for egit/jgit and MPC for now since the original classic also didn't have them. Doing a binary diff of the "old SDK" and the "new SDK" on win32, I see that "binary file differs" for all the plugins/*.jar - even those that come from Orbit. Looking into one of the bundles, I see that - eclipse.inf is only packaged into the EPP "new SDK" but not the Platform SDK This looks like a defect in the Platform SDK to me, I have filed bug 403589 . Other than that, the differences I've noticed are 1. org.eclipse.cvs.source feature missing in "new SDK" I think this should be added to epp.classic. 2. The product ID is different in the "new SDK" : platform.ide rather than sdk - this shows in eclipse.ini , config.ini ; and the SDK bundle is missing. As a result, a number of customizations from the Platform SDK product bundle are missing; some primary wizards, the Capability / Activity definitions, and more (visible when comparing plugin.xml of the two product bundles). Markus, do you see a chance adopting Platform SDK as the product bundle rather than rolling our own with an EPP Product bundle ? 3. The new SDK sets the following vmargs, I think this is OK -Dosgi.requiredJavaVersion=1.6 -Dhelp.lucene.tokenizer=standard (In reply to comment #28) > 2. The product ID is different in the "new SDK" : platform.ide rather than > sdk > - this shows in eclipse.ini , config.ini ; and the SDK bundle is missing. > As a result, a number of customizations from the Platform SDK product > bundle > are missing; some primary wizards, the Capability / Activity definitions, > and more (visible when comparing plugin.xml of the two product bundles). > Markus, do you see a chance adopting Platform SDK as the product bundle > rather than rolling our own with an EPP Product bundle ? > Off hand, I'd think you'd want your own product ID, to reflect coming from EPP land ... but, not sure there's any technical reason you'd have to (not that I would know). But, I do know, if you have your own product ID and branding bundle, then you do need your own "Capabilities definitions", (perhaps some welcome screen type stuff ... have it named there, etc.?). I know this only because when we did it for JEE EPP package, we had to provide our own, and basically just made a copy of what was in Eclipse SDK. At that time, I was pointed to some long standing feature request to make "product definitions" more "reusable" in new products, but as far as I know, no work has been done in that area. Thanks David. I understand that I could just copy the org.eclipse.sdk bundle definitions into the EPP product bundle, but knowing that any such copy will soon run apart I'd rather "reference" or "re-use" the original product definition. The purpose of the classic bundle in particular is being identical to Platform SDK except for egit and mpc, so I'd like any changes that the Platform team decides to make in the org.eclipse.sdk product bundle be reflected in the related epp product without extra maintenance, if possible. (In reply to comment #28) > 1. org.eclipse.cvs.source feature missing in "new SDK" The final decision is up to the package maintainer... grumpy Markus (who doesn't like these source bundles) has added the source feature... ;-) > 2. The product ID is different in the "new SDK" : platform.ide rather than > sdk That's the way all EPP packages have been built in the past... I propose to leave it like it is for M6, but I'd like to go on with this discussion to find out if a change is required/possible for M7 and if so, what kind of change. > 3. The new SDK sets the following vmargs, I think this is OK > -Dosgi.requiredJavaVersion=1.6 > -Dhelp.lucene.tokenizer=standard I like a certain level of consistency between all packages and I think these arguments make sense, especially the minimum required Java version. (In reply to comment #31) > (In reply to comment #28) > > > 3. The new SDK sets the following vmargs, I think this is OK > > -Dosgi.requiredJavaVersion=1.6 > > -Dhelp.lucene.tokenizer=standard > > I like a certain level of consistency between all packages and I think these > arguments make sense, especially the minimum required Java version. I'm 95% sure -Dhelp.lucene.tokenizer=standard can be removed in Kepler. Now that the platform has moved up to lucene 3.5. See bug 340563 and bug 382574 for (lots) of history. Created attachment 228560 [details] org.eclipse.sdk bundle as of 4.3m6 (In reply to comment #31) > > 2. The product ID is different in the "new SDK" : platform.ide rather than > > sdk > > That's the way all EPP packages have been built in the past... I propose to > leave it like it is for M6, but I'd like to go on with this discussion to So, then you propose merging all the contents of the org.eclipse.sdk bundle from the "old classic" into the org.eclipse.epp.package.classic bundle ? I think this is necessary, because right now the differences between "old classic" and "new classic" are vast: - Intro theme should be "Slate" - Different icon colors and sizes available - Missing Capability definitions - Missing Primiary Wizard definitions - Errorlog entry about some missing intro contents on startup I'm attaching the contents of org.eclipse.sdk (as of 4.3m6) for reference. Actually, this might also be an opportunity to update the product/branding bundle of other packages as well. The "Circles" Theme looks really lame these days IMO... Hi Markus, how do you think we shall proceed on the necessary changes to the package's product bundle ? - I think there's some must-have changes in there or the package won't be accepted as an "Eclipse Classic" replacement. I think it's a simple cloning exercise and I'd do it myself if I had commit rights already ... what do you suggest ? I'd hate having to fall back to plan B and keep the "original classic" on downloads for M6. Thanks Martin I won't have any time to work on it for M6. That's how it is... sorry for that. I did spend some time on it last weekend, but now I'm running out of time. Either you are cloning the EPP repository and send me a patch that works out of the box, or we need to release what we have right now as M6. I don't think it is necessary to fall back to the old SDK on the development tab of the download page, because (a) it's still there, and (b) we need to show that we are moving into the right direction with the EPP Classic package for M6. (In reply to comment #36) I can work on a patch in git, but regarding "works out of the box" I'm not sure how I could test it? Is epp Gerrit-enabled, with Hudson verification builds? The github mirror of epp is unfortunately old (another case of bug 402183) but I guess I can make another manual clone on github with my own account, then you can pull from the public clone - I assume that is easier than attaching a patch. Regarding the "fallback" , are you proposing to simply keep the "old classing" on eclipse.org/downloads for M6 and making the "new classic" available via the EPP download page only ? Then IMO we couldn't claim that this bug is "fixed" by M6. (In reply to comment #37) > I can work on a patch in git, but regarding "works out of the box" I'm not > sure how I could test it? Is epp Gerrit-enabled, with Hudson verification > builds? No, it's not "Gerrit-enabled". > The github mirror of epp is unfortunately old (another case of bug 402183) > but I guess I can make another manual clone on github with my own account, > then you can pull from the public clone - I assume that is easier than > attaching a patch. Yep, that's true... it's a bit easier to fetch and merge changes from another Git repository. > Regarding the "fallback" , are you proposing to simply keep the "old > classing" on eclipse.org/downloads for M6 and making the "new classic" > available via the EPP download page only ? Then IMO we couldn't claim that > this bug is "fixed" by M6. I don't expect that we can "close" this bug as fixed with M6; I take this bug more as an umbrella bug that documents the discussion and the work that is done on the EPP Classic package. I didn't mean to sound rude yesterday in my last comment, I just wanted to set the expectations to a more realistic level. The issues that you mentioned in your comments are all going into the right direction (I think) and we should definitively work on these issues, but the EPP packages for M6 need to be ready today (in fact: they are already build). The time window to build the EPP Classic/SDK for M6 was very short and we need to live with what we have. Today it's more a decision with limited options: Have EPP Classic/SDK on the "developers" tab on the download page [1], or the old Classic/SDK . And in this decision I vote for the EPP version instead of the old one for a number of reasons: First and very important is a signal to adopters who can see that there will be an EPP replacement in Kepler, that there is progress on defining the final package, and that they may need to adjust their setup. Second, it is a signal to the consumers, i.e. developers using this package. I think that with the inclusion of EGit the EPP version will better suit the needs of the majority of the users. And then there's always the possibility to download the old Classic/SDK from the old location for those that really need that one. IMO we should not wait until M7 to make the new EPP version available. [1] http://www.eclipse.org/downloads/index-developer.php (In reply to comment #38) > Today it's more a decision with limited options: Have EPP Classic/SDK on the > "developers" tab on the download page [1], or the old Classic/SDK . And in > this decision I vote for the EPP version instead of the old one for a number Sorry, but as a package maintainer I have to veto that. I won't accept a package on the main download page [1] that I know is broken... it failed my most primitive acceptance tests. It produces errorlogs, has an improper branding, improper Intro, and improper Capability defs. These things are really trivial to fix by simply copying from the old classic. I want the "new classic" to be solid on the EPP downloads page before promoting it to the main downloads page [1]. One question: On the main downloads page [1], is it possible to change the description text adding a note like "This legacy classic page will be replaced with an EPP classic page in M7. See bug 397896 for details". This gives adopters advance notice for M7, shows our progress, allows them to download M7 pre-packages if they want, and even allows them to influence the discussion if they want. [1] http://www.eclipse.org/downloads/index-developer.php (In reply to comment #39) > (In reply to comment #38) > > Today it's more a decision with limited options: Have EPP Classic/SDK on the > > "developers" tab on the download page [1], or the old Classic/SDK . And in > > this decision I vote for the EPP version instead of the old one for a number > > > Sorry, but as a package maintainer I have to veto that. > > I won't accept a package on the main download page [1] that I know is > broken... it failed my most primitive acceptance tests. It produces > errorlogs, has an improper branding, improper Intro, and improper Capability > defs. Martin can you elaborate on these problems. Things like branding and intro seem like non-blocking bugs for an M6 release. I would think getting feedback on the actualy package contents is more important. (In reply to comment #40) > Martin can you elaborate on these problems. Things like branding and intro > seem like non-blocking bugs for an M6 release. I would think getting > feedback on the actualy package contents is more important. The package simply does not behave as expected. If we want to get feedback, we also need a feedback channel. For that, please consider my proposal of adding a textual note to the download. The textual note is essential regardless of what package is the default one to download (old classic or new classic). Personally, I don't want to force something broken onto adopters, not even in a milestone, and particularly not at the Eclipse milestone M6. (In reply to comment #41) > (In reply to comment #40) > > Martin can you elaborate on these problems. Things like branding and intro > > seem like non-blocking bugs for an M6 release. I would think getting > > feedback on the actualy package contents is more important. > > > The package simply does not behave as expected. Hmmm, makes me wonder why adding eGit and MPC is causing so much problem. > > If we want to get feedback, we also need a feedback channel. For that, > please consider my proposal of adding a textual note to the download. The > textual note is essential regardless of what package is the default one to > download (old classic or new classic). There is a feedback loop for all packages already. Under the details link there is a place for reporting a bug. > > Personally, I don't want to force something broken onto adopters, not even > in a milestone, and particularly not at the Eclipse milestone M6. ok, your call but I would remind you that if you want feedback you need to get something in front of people. No one reads textual notes. We know this from lots and lots of years of experience. (In reply to comment #42) > Hmmm, makes me wonder why adding eGit and MPC is causing so much problem. The problem is not eGit and MPC - the problem is that the branding bundle (org.eclipse.sdk) is missing and instead we have an EPP branding bundle which is based on Eclipse Platform but not SDK. I have mentioned that in comment 28. The result of not having the SDK Branding bundle is: - The Welcome page comes with the old "circles" look and not the new "slate" - The default perspective is "PDE" and not "Java" - The "Capabilities" Preference Page is missing (this is probably the most severe of all issues since it makes selective enablement of Capabilities impossible) - This is printed into the errorlog: java.io.FileNotFoundException: D:\Eclipse\eclipse4.3m6.epp03161738\eclipse\introData.xml (The system cannot find the file specified) - The CSS/Styling of help contents is lame (visible when you Help > Contents, then click on "Platform plug-in developer guide" - Capability defs missing under Preferences > All in all, the issues are probably not as bad as I have thought - especially taking into account that we can assume all the other packages have suffered from these issues as well in the past... I will think again about my decision, until when do I need to make up my mind ? > There is a feedback loop for all packages already. Under the details link > there is a place for reporting a bug. That link is way too hidden. Even now that you told me it exists, I had to search for half a minute until I found it. You cannot call that a feedback loop. I do see something interesting in the package description though, it says "Please also look at the Eclipse Project Download Page" and that page is hyperlinked. If there is any way editing that package description text, I'd like to go for it -- mentioning that we now have a new classic, adding the "Report a Bug" hyperlink and mentioning that the "old" classic is still available form the Eclipse project download pages. > ok, your call but I would remind you that if you want feedback you need to > get something in front of people. No one reads textual notes. We know this > from lots and lots of years of experience. Point taken, but the feedback loop must exist in a more obvious place. The way it is today, I'm not surprised you didn't get feedback. If I may, here's my personal 2 ct. from the point of view of a Release Train consumer, both as an end user as well as someone "living downstream" and building on top of the release: (In reply to comment #42) > if you want feedback you need to get > something in front of people. No one reads textual notes. We know this from > lots and lots of years of experience. +1 - If I weren't already up to speed on this bug, I'd appreciate the heads-up in the form of the new bundle on the download page. Especially when "looking in from the outside" on the release train, it can be a challenge to stay on top of everything significant going on. So my vote is for an in-your-face approach to make people aware of this change as early as feasible :) (In reply to comment #39) > One question: On the main downloads page [1], is it possible to change the > description text adding a note like "This legacy classic page will be replaced > with an EPP classic page in M7. See bug 397896 for details". Do you mean the main page listing all the available downloads? Or the SDK bundle's detail page? On the former, I currently don't see any description text besides the package name. The latter I think wouldn't be visible enough. (In reply to comment #43) > All in all, the issues are probably not as bad as I have thought They might not be optimal, but weighing them against the early visibility of the new package, as a user I wouldn't mind on a milestone build. > I do see something interesting in the package description though, it says > "Please also look at the Eclipse Project Download Page" and that page is > hyperlinked. If there is any way editing that package description text, I'd like > to go for it -- mentioning that we now have a new classic, adding the "Report a > Bug" hyperlink and mentioning that the "old" classic is still available form the > Eclipse project download pages. +1 - I like that. It communicates what's going on wrt the old and new SDK packages. I assume that the new package will retain the "Other Downloads" link on the download overview page? Did you subscribe to epp-dev https://dev.eclipse.org/mailman/listinfo/epp-dev? That's the main communication channel and I asked the package maintainers for their Kepler M6 votes this afternoon (http://dev.eclipse.org/mhonarc/lists/epp-dev/msg02440.html). The title and the description of every package is maintained in a separate XML file for every package. The initial one for the EPP Classic package can be found here: http://git.eclipse.org/c/epp/org.eclipse.epp.packages.git/tree/packages/org.eclipse.epp.package.classic.feature/epp.website.xml - especially the description element could be interesting. It is the text that is visible on the details page. Ok, I have forked the epp.packages repo on github and implemented a description that I find reasonable. Please pull my change: https://github.com/moberhuber/epp.packages/commit/c15b3d5fb3d1aa8feccbd43faa142c34de0f2484 Of course I confirm that I understand and consent to all points of the CoO: http://www.eclipse.org/legal/CoO.php I've written the new text from scratch, I contribute it under the EPL and my employer authorizes me to do so ... Is there a chance to preview / test the new description ? I have now also updated the epp.package.classic product bundle, please pull from my github fork: git://github.com/moberhuber/epp.packages.git b72e68e64ac6df7662723c79ae169d6da92a2bee I have only referenced code under the EPL (that is, the Eclipse SDK product bundle). I'm submitting my changes under the EPL and I have the right to do so. (In reply to comment #46) > Ok, I have forked the epp.packages repo on github and implemented a > description that I find reasonable. Please pull my change: > > https://github.com/moberhuber/epp.packages/commit/ > c15b3d5fb3d1aa8feccbd43faa142c34de0f2484 Pushed to master. > Is there a chance to preview / test the new description ? Unfortunately not... I've created the new 'classic-package' component in Bugzilla and updated the epp.website.xml file accordingly. Excellent - thanks so much ! The website is actually available for review, and the package has been downloaded 47 times already at the time of this writing: http://www.eclipse.org/downloads/packages/eclipse-classic-43-m6/keplerm6 I have fixed the "click here to file a bug" URL in the description, to point to the new bugzilla component; also slightly improved description layout by removing one linebreak. Please consider pulling from github: https://github.com/moberhuber/epp.packages/commit/59b587d3773681b211c893d01c0b5230bc558e8a I'm closing this bug as per Kepler M6, since the "new classic" package including EGit and MPC has been defined and is available. Remaining issues with missing configuration from the SDK bundle is tracked in https://bugs.eclipse.org/bugs/show_bug.cgi?id=404165 . Please file any new issues as new bugs against the "classic-package" component. Just to document the changes and updates here The commit b72e68e64ac6df7662723c79ae169d6da92a2bee "Classic package: sync-up classic product bundle with Eclipse SDK" in comment 47 has been merged into master now (commit 8283f5beda8b1893e5e2ced7e39b5ad659092ad4). The commit 59b587d3773681b211c893d01c0b5230bc558e8a "classic website: fix URL in description for filing a bug" in comment 50 has been picked up with commit 3aaead0bad3b12f167e0ae4702bc9dcd622fe127 in master. |