Bugzilla – Full Text Bug Listing
| Summary: | Remove CVS from Eclipse SDK feature | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Alex Blewitt <alex.blewitt> |
| Component: | Releng | Assignee: | Sravan Kumar Lakkimsetti <sravankumarl> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ahunter.eclipse, akurtakov, bugs.eclipse.org, contact, daniel_megert, david_williams, eclipse-bugs, ian.skerrett, irbull, jesse.mcconnell, john.arthorne, kim.moir, Lars.Vogel, loskutov, markus.kell.r, Mike_Wilson, mistria, pwebster, remy.suen, sbouchet, Szymon.Brandys, thatnitind, wayne.beaton |
| Version: | 4.1 | Keywords: | noteworthy |
| Target Milestone: | 4.8 M4 | Flags: | daniel_megert:
pmc_approved+
|
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=438297 https://git.eclipse.org/r/110849 https://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=aa65bbca4d12fc9d7919cad26b4d85a05b926489 https://git.eclipse.org/r/110971 https://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=5c3920515acb0bf8a9af9a51743b174e52cb5769 |
||
| Whiteboard: | |||
| Bug Depends on: | 359465 | ||
| Bug Blocks: | 527936 | ||
|
Description
Alex Blewitt
John, does the PMC have a comment on proceeding with this change? I know it was discussed before. One thing to consider, looking at the numbers from the Eclipse membership meeting this morning, a significant percentage of Eclipse projects still host their code in CVS. That being said, they could install the CVS tooling from the repo if it wasn't included by default in the SDK. We're turning up the heat on Eclipse projects to convert to Git. The magic "turn of CVS" date is December 21/2012. Projects really need to be done well in advance of this date. Targetting a change immediately following the Juno release is what I'm encouraging. In the meantime, we're going to push to get Phoenix, Babel, Dash, and Examples all moved over to Git either next quarter or early in the next. The project websites will follow shortly thereafter. Removing CVS from the SDK would be much-needed additional motivation for projects to move. Having said that, there are other consumers of the SDK that should be considered. What is the impact on users and adopters? I agree to remove CVS but doing this for 3.8 / 4.2 is probably too short notice. Another question is whether we want to include EGit instead. The SDK is here to develop plug-ins. One of the features is that you can easily check out an SDK bundle via Import > 'Plug-ins and Fragments' from the repository but of course that only works if EGit is installed. (In reply to comment #3) > I agree to remove CVS but doing this for 3.8 / 4.2 is probably too short > notice. Why would it be short notice? 3.8M2 has only just gone out the door, there's several milestones left. Why not remove it now, and then if there is a fuss, put it back in for 3.8M5 or similar? At least trying to remove it now would be a good start, even if it's found necessary to move back in for a subsequent release. As for EGit being part of the SDK - that probably makes sense to me, particularly with the way the repositories are all moving over to Git. Should that be a separate bug? > Why would it be short notice? The CVS bundles are listed in the official 3.8 and 4.2 plans. We have to check with consumers before changing this. > Should that be a separate bug? We'll discuss it all together in the PMC meeting. We can open a new bug later if required. The goal of the SDK package is to provide an out-of-the-box environment for Eclipse plug-in developers. It should be complete enough so that work can get done without additional plug-ins. As long as some plug-ins from the SDK still live in CVS (e.g. Orbit), the CVS support should stay. I agree that EGit should be added to the SDK. (In reply to comment #6) > The goal of the SDK package is to provide an out-of-the-box environment for > Eclipse plug-in developers. It should be complete enough so that work can get > done without additional plug-ins. Strictly speaking, it is a software development kit for building plug-ins and products based on Eclipse technology. Not all people building plug-ins and products are necessarily doing so at eclipse.org. I am neither for, nor against removing CVS from the SDK. I just believe that it must be a separate discussion from the retirement of CVS at eclipse.org Also, keep in mind that the SDK is different from the EPP packages. We may need to have this discussion with the package maintainers as well. I am in favour of removing CVS from the 4.2 SDK, but leaving it in 3.8 since the focus there is on stability and consistency. We have had a couple of PMC discussions about this but we'll revisit it again next week before deciding. On eGit, my current position is we exclude all forms of version control from the SDK and have them be separate installs. Logically eGit should be included because we are using Git, but I think the build-time circularity pain is not worth the extra effort. eGit is a +3 project but Eclipse SDK is +0. Having a separate eGit install that is upgraded each time you upgrade your SDK is not too difficult. Also our releng tools will soon have a dependency on eGit, so installing Releng Tools will also install eGit for you. In the end this means no extra effort for Eclipse project contributors. For reference, here are notes from some of our past discussions on this: http://wiki.eclipse.org/Platform-releng/Juno_Git_Migration#Including_eGit_in_Eclipse_SDK http://wiki.eclipse.org/Eclipse/PMC#20110615 > but I think the build-time circularity pain is not
> worth the extra effort. eGit is a +3 project but Eclipse SDK is +0.
Good point.
Coming from the general-user-community perspective, I have a couple of points to make. 1) On the downloads page, the SDK is still featured prominently (as "Eclipse Classic," typically the second most downloaded package from the downloads page), meaning lots of newbies and "casual" Eclipse users download it. If CVS were to be removed, that means there will be lots of "Eclipse doesn't have SCM support built-in?!" questions/claims. Doesn't matter how much we say that it's easy to install, we see this kind of thing come up again and again in the forums; newbies just aren't accustomed to their IDE missing stuff right out of the box. 2) EPP packages should (without a doubt, in my opinion) continue to include CVS support, regardless of the decision about the SDK. Just because git makes a lot of sense for certain kinds of projects, it makes far less sense for other types of projects and many corporate/enterprise environments aren't on the bandwagon yet. Similar to point 1 above, we can't afford for Eclipse to appear to not support expected technology. It doesn't matter if you don't like CVS, I think it's on the "expected" feature list for an IDE even today. > build-time circularity pain
I don't understand the pain. This is the same situation as with the current CVS support and with the builder. Releng just uses a stable build to create the new builds, so there's no circularity.
Furthermore, if releng tools depend on EGit, does that mean they also become +3? I'd rather have everything in +0.
The "Eclipse Classic" name would also have to be revised if the SDK build suddenly didn't contain the classic plug-ins any more.
We've heard a lot of strong arguments for retaining CVS at least for Juno.
What are the argument for removing it?
- "it's old and I don't like it"
- save a few bytes
- put pressure on people for moving to Git (a questionable goal to enforce -- once EGit is good enough, the masses will pull it automatically)
=> not too convincing...
+1 for leaving CVS support in the EPP packages and SDK. Removing it will definitely cause problems for some portion of our user community and I see very little benefit from removing it. I figure if the argument is to be agnostic to SCM then we ought to be agnostic to build tooling and remove support for ant and anything else bespoke that might come with eclipse... seriously though, I don't see why there isn't a simple bare bones distro that people can install whatever they need/want into, and then the traditional fat ones that everyone uses right now filled to the brim with whatever folks want to cram into them. No reason you can't have cvs + git (and svn if licensing was ever cleared up) in the default fat download. in general I agree with Markus though in terms of how you effect the outside world...within eclipse lock down cvs and terminate it with extreme prejudice...but let the masses make whatever mistakes they want by using cvs and if a large percentage of people expect it in the eclipse download, let it stay. just forbid eclipse projects from ever touching it again which can easily be done by shutting down the ports that support it :) (In reply to comment #13) > seriously though, I don't see why there isn't a simple bare bones distro that > people can install whatever they need/want into, and then the traditional fat > ones that everyone uses right now filled to the brim with whatever folks want > to cram into them. No reason you can't have cvs + git (and svn if licensing > was ever cleared up) in the default fat download. Platform Runtime Binary. Markus: The build-time circularity pain is that EGit is provided as +3 and we are +0. Thus we need to release a milestone before the EGit team would have their milestone bundles ready. This doesn't happen today because the CVS bundles are built as part of the SDK. > Markus: The build-time circularity pain is that EGit is provided as +3
Ah, I see. So EGit would just have to move to +0 and everything is fine ;-).
(In reply to comment #16) > Ah, I see. So EGit would just have to move to +0 and everything is fine ;-). Yes, the problem is that we would need to include the final eGit build in our various zip files. This turns out to be quite difficult even for components that have very few or no external dependencies. We do this today for ECF and EMF which are included in our builds. For these two cases we have agreement from those teams that they produce their components before our build, so they are effectively -1 day components. Whenever we add such a dependency in our build we add risk of last minute destabilization or missing our build dates due to a prerequisite rebuild. EPP is really designed as the place where such aggregated products are built, which is why it runs at the end after all other projects are done. The Releng Tools dependency on eGit is different. It just requires eGit rather than actually including it in a zip or repo. So at install time p2 just grabs the latest eGit that fits the dependency range, which could have been built much later than Releng Tools itself. I understand the current reality that Eclipse Classic is one of the favorite community downloads, but I don't like the idea of deciding what's in that package based on our guess of what the community wants. I think the package would look quite different if community popularity was our criterion for selecting its contents. I believe SVN and Git are both more popular than CVS for open source projects, for example. On the other hand, the Eclipse Classic download stats clearly show it is fulfilling a real community demand that other EPP packages aren't covering. Crazy idea: maybe we should remove Eclipse Classic from the main eclipse.org downloads page entirely, and replace it with an EPP package called "Eclipse IDE for Plugin Developers" or similar. That package could contain CVS, eGit, and any other package we decide is important for the wider community of plugin developers (perhaps based on Ian's community surveys or other objective inputs). It could exclude source code because the target would be people building arbitrary plugins rather than developers of the SDK itself. (In reply to comment #18) > Crazy idea: maybe we should remove Eclipse Classic from the main eclipse.org > downloads page entirely, and replace it with an EPP package called "Eclipse IDE > for Plugin Developers" or similar. That package could contain CVS, eGit, and > any other package we decide is important for the wider community of plugin > developers (perhaps based on Ian's community surveys or other objective > inputs). It could exclude source code because the target would be people > building arbitrary plugins rather than developers of the SDK itself. We already ship "Eclipse for RCP and RAP Developers"; I've been using it for years... One more data-point: Our community surveys consistently list CVS as the second most used VCS (after SVN). I'm trying to find a link to the survey results. (In reply to comment #20) > One more data-point: Our community surveys consistently list CVS as the second > most used VCS (after SVN). I'm trying to find a link to the survey results. Ah... there it is http://www.eclipse.org/org/community_survey/Eclipse_Survey_2010_Report.pdf Look for "Tools: Source Code, Change, and Build Management" SVN 58.3% CVS 12.6% Git 6.8% That's in 2010. I imagine that the numbers have shifted a bit since then. (In reply to comment #19) > We already ship "Eclipse for RCP and RAP Developers"; I've been using it for > years... Yes, but judging by the download counts it's not very popular. I suspect many regular end users don't know what RAP is so they don't realize that download is applicable. I assumed this package included the RAP server prerequisites, until just now when I looked at the details. I agree this package is essentially what I was thinking of (Eclipse SDK + EGit + Mylyn + XML editor). (In reply to comment #18) > I understand the current reality that Eclipse Classic is one of the favorite > community downloads, but I don't like the idea of deciding what's in that > package based on our guess of what the community wants. I think the package > would look quite different if community popularity was our criterion for > selecting its contents. I believe SVN and Git are both more popular than CVS > for open source projects, for example. On the other hand, the Eclipse Classic > download stats clearly show it is fulfilling a real community demand that other > EPP packages aren't covering. > > Crazy idea: maybe we should remove Eclipse Classic from the main eclipse.org > downloads page entirely I would wholeheartedly support removing Eclipse Classic, despite it's place as 2nd most popular download. I just find it hard to believe that most Eclipse users really want or need PDE or the source code that comes with it. I think people are misled by the name and it's placement. Maybe instead of removing, just renaming it to better reflect what it is. I recall a bugzilla discussion about this very topic a year or two ago; IIRC the outcome was that we should no remove such a prominent item from the Downloads page late in a release cycle. We have a chance to change that now for Juno, but not if we wait too long. The earlier discussion I was thinking of is bug 273930 In some "hallway talk", I heard it suggested (and I think a good idea) it that before removing cvs bundles/features from the Platform, that it be made easier to get (any) SCM providers by using "p2 discovery" mechanisms specifically for SCM providers. A menu item, or link, could appear, for example, on the "Team" preference page. (It is tempting to "make real easy" by putting on the Help menu itself, next to "Install new software", but I think that would be too much ... making that menu too "busy" for everyone, even if they had scm support already). When implemented, hopefully, it can be done in a "reusable" form, so that other points of entry could use it, such as if some someone selects "import from repository" but did not have the code needed to access that SCM repository a dialog could be brought up asking if they wanted to install an adapter for that repository. Additionally, I suppose, CVS could/should also go into an entry/category in "market place client"? Note, there are others that use the p2 discovery API, Mylyn probably the first (best?) example (that I know of). I know Server Tools uses something similar on "Server" preferences in WTP, but I don't think they have migrated to the official p2 discovery API. So ... just wanted to capture that good hallway discussion (and the ideas of others :) ... if it hasn't been document elsewhere. Should these sorts of enhancements be tracked in separate bugzilla entries? Any volunteers to implement? :) We discussed this in the Eclipse PMC on October 5th: http://wiki.eclipse.org/Eclipse/PMC We decided against removing CVS for Juno release. There is no strong argument for removing it, so it is hard to argue it is worth the disruption to user community. In the long run we would like CVS to be removed and would like it to be just as easy to install any SCM into the platform. We would like to see the p2 discovery UI used to make it trivial to add SCM support into SDK (e.g., Help > Add Version Control > CVS). Once we had that in place we would be in a better position to remove all version control from the SDK by default. (In reply to comment #26) > ... We would like to see the > p2 discovery UI used to make it trivial to add SCM support into SDK > (e.g., Help > Add Version Control > CVS). I know you just meant as an example, but please don't put it right under "Help". For one, once a user adds such support, it'd then be noise forever to that user, and also, if an adopter or EPP package adds their own SCM support for their package, it is likewise noise to most users. I am sensitive to this since, in the past, I have seen a temptation for everyone to put "install more of our stuff" directly under the Help menu, which isn't scalable. It'd be better under "Preferences", "Team". How about some kind of "Configure Eclipse" functionality that steps the user through installing team providers, language support, Mylyn, HTML editor, other features, etc.? It'd be very cool, IMHO, if we could strip down the distribution to something akin to the Platform Runtime Binaries with pluggable customization on the desktop. (In reply to comment #26) > We discussed this in the Eclipse PMC on October 5th: > > http://wiki.eclipse.org/Eclipse/PMC > > We decided against removing CVS for Juno release. There is no strong > argument for removing it, so it is hard to argue it is worth the disruption > to user community. In the long run we would like CVS to be removed and would > like it to be just as easy to install any SCM into the platform. We would > like to see the p2 discovery UI used to make it trivial to add SCM support > into SDK (e.g., Help > Add Version Control > CVS). Once we had that in place > we would be in a better position to remove all version control from the SDK > by default. Now that we are on the Kepler release and very likely the majority will not be using CVS anymore, can we remove CVS from the SDK now? Not sure how the other Eclipse committers feel, but it is very annoying having the CVS in the SDK by default and git absent. (In reply to comment #29) > (In reply to comment #26) > > We discussed this in the Eclipse PMC on October 5th: > > > > http://wiki.eclipse.org/Eclipse/PMC > > > > We decided against removing CVS for Juno release. There is no strong > > argument for removing it, so it is hard to argue it is worth the disruption > > to user community. In the long run we would like CVS to be removed and would > > like it to be just as easy to install any SCM into the platform. We would > > like to see the p2 discovery UI used to make it trivial to add SCM support > > into SDK (e.g., Help > Add Version Control > CVS). Once we had that in place > > we would be in a better position to remove all version control from the SDK > > by default. > > Now that we are on the Kepler release and very likely the majority will not > be using CVS anymore, can we remove CVS from the SDK now? > > Not sure how the other Eclipse committers feel, but it is very annoying > having the CVS in the SDK by default and git absent. I'll put it on the agenda for next Wednesday's PMC call. For me, more appealing than removing CVS would be to have EGit included. (In reply to comment #29) > Now that we are on the Kepler release and very likely the majority will not > be using CVS anymore, can we remove CVS from the SDK now? > > Not sure how the other Eclipse committers feel, but it is very annoying > having the CVS in the SDK by default and git absent. There are millions of people who download Eclipse, only a few hundred of which are Eclipse committers. The main argument against removing it is that for at least some part of that community it is disruptive to remove it. If they are building a product based on the SDK they will have to intervene to add it back if needed for their own customers. For us Eclipse committers it really doesn't do any harm being present. I agree it would be convenient to have eGit in the SDK. The main problem is it creates a circular dependency between our builds. eGit is a +3 project on the release train, which would make Eclipse SDK +4. The solution to this is that we stop producing the Eclipse SDK in our +0 build at all, and it is just another EPP package that gets built at the end of each milestone. On the other hand there are already several EPP packages containing eGit, that for most of the community is probably good enough. (In reply to comment #31) > There are millions of people who download Eclipse, only a few hundred of > which are Eclipse committers. The main argument against removing it is that > for at least some part of that community it is disruptive to remove it. If > they are building a product based on the SDK they will have to intervene to > add it back if needed for their own customers. For us Eclipse committers it > really doesn't do any harm being present. I believe that it's fair to say (unfortunately the download numbers look broken right now) that most consumers--especially the ones who would miss CVS--download one of the EPP packages rather than the SDK. In that context, I'm not sure that too many people would miss CVS in the SDK. Or care if it's present for that matter. In that context, it is the package maintainers that need to decide whether or not their consumers expect CVS to be included. I don't have a strong opinion regarding whether or not CVS should be included in the SDK. Adopters who care about it should be able to pretty easily sort out how to include it (or, conversely, remove it). (In reply to comment #31) > I agree it would be convenient to have eGit in the SDK. The main problem is > it creates a circular dependency between our builds. eGit is a +3 project on > the release train, which would make Eclipse SDK +4. The solution to this is > that we stop producing the Eclipse SDK in our +0 build at all, and it is > just another EPP package that gets built at the end of each milestone. On > the other hand there are already several EPP packages containing eGit, that > for most of the community is probably good enough. By definition, the Eclipse SDK has been a single download that gives you everything you need to develop Eclipse, so having to install EGit separately doesn't feel right (ok, you could argue that we never shipped releng tools either). Is there a technical reason why EGit is +3 (instead of simply a +1). The reason I ask is because a +1 could likely become a +0 (we do that with EMF now if I'm not mistaken). This would certainly be a nice to have as it makes the SDK story a little cleaner. However, I'm not sure how many people simply download the SDK anymore (according to our download page, the answer is 0 [1], although I don't really believe that :-) ). [1] http://www.eclipse.org/downloads/ I believe we should keep CVS in the SDK. I can't see what is the huge benefit for having to removed but I can see annoying a lot of people. @irbull we will get the download numbers fixed for Classic. The Eclipse PMC has discussed this and decided to leave CVS in the SDK for the following reasons: 1) Those who want to start without CVS can download the 'Platform Runtime Binary' and then install Git (or whatever team providers) into it. 2) Besides a smaller download, removing CVS does not bring any value but can break existing users of the SDK download. 3) The Eclipse packages (EPP) are the correct solution to group different Eclipse deliverables into a meaningful download. Unfortunately, some of them are currently missing Git. I'll file bugs for that. Whether package owners also remove CVS is up to them. 4) The Eclipse project does not want to start adding more team providers to the SDK. Hi, i haven't read all comments but only the last ones. i want to give my 2cts here. I am an eclipse commiter and i develop application on top of eclipse/rcp. I am using SDK as primary IDE. I am not using CVS anymore, but not Egit either. For me, Eclipse SDK should only provide Eclipse classic sources. any other plugins ( cvs, egit, releng, marketplace...) can be downloaded separately, or by provided as an EPP package. that is, having an Eclipse EPP SDK package with CVS. The only pain for actual users of SDK i can see is the miss of cvs when downloading 'historic' eclipse sdk. EMO did a great job moving from CVS, why keep it on downloadable package ? Note that there is an ongoing discussion (and a beginning of consensus) about removing CVS from EPP packages: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10790.html Since SDK isn't about to change on that, here is a reminder of the request to EPP: https://bugs.eclipse.org/bugs/show_bug.cgi?id=438297 The PMC reconsidered this. For details see https://wiki.eclipse.org/Eclipse/PMC (In reply to Dani Megert from comment #39) > The PMC reconsidered this. For details see > https://wiki.eclipse.org/Eclipse/PMC To be explicit, can we assume it will still be built, and made available in the platform's repository? (In reply to David Williams from comment #40) > (In reply to Dani Megert from comment #39) > > The PMC reconsidered this. For details see > > https://wiki.eclipse.org/Eclipse/PMC > > To be explicit, can we assume it will still be built, and made available in > the platform's repository? Yes, CVS will not be part of the SDK download but the separate download will still be there and it will be part of the p2 repository too. Too late for M3 now. Sravan, please do this right after M3. *** Bug 526629 has been marked as a duplicate of this bug. *** New Gerrit change created: https://git.eclipse.org/r/110849 Gerrit change https://git.eclipse.org/r/110849 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=aa65bbca4d12fc9d7919cad26b4d85a05b926489 I hope this will not break the build, please revert if it causes any issues. New Gerrit change created: https://git.eclipse.org/r/110971 New Gerrit change created: https://git.eclipse.org/r/110971 Gerrit change https://git.eclipse.org/r/110971 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=5c3920515acb0bf8a9af9a51743b174e52cb5769 Gerrit change https://git.eclipse.org/r/110971 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=5c3920515acb0bf8a9af9a51743b174e52cb5769 Revert as this caused the build to fail Sravan, the final goal is: - CVS removed from SDK (feature) - CVS tests still run - CVS Runtime and CVS SDK must still be produced Removed CVS bundle through https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=bb71faa57f0aeee3bddca665465cdb38932bcd1e and https://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=74a32125fe5113dbc1393bc9679a94541cc9479c Verified by in I20171129-2000. |