BTW, we have a new mailing list that's getting created tonight, ide-dev, which is probably a better place for these types of discussion (since most of the packages are IDE packages). Look for it tomorrow.
From: Doug Schaefer <[email protected]<mailto:[email protected]>> Reply-To: Cross project issues <[email protected]<mailto:[email protected]>> Date: Monday, 29 July, 2013 8:16 PM To: Cross project issues <[email protected]<mailto:[email protected]>> Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? That's great question I was asking myself looking at the Download page the other day. I don't think I have a great answer though. I like the idea of the big uber package for the reason you list as #3. I'd like to fix our tools plug-ins to play nicer together. Having this package would give us a test bed to work towards. But it's probably not a great idea for end users, at least not yet. And it certainly isn't a good idea for the Eclipse infrastructure and would chew through way too much bandwidth. Maybe we can use or adapt the Ecilpse Marketplace to make it easier to load up components. The p2 UI is pretty tough on new users. Marketplace client is a much better experience but it's still hard to discover things. But we could provide our own catalog to accomplish this goal. Doug. From: Konstantin Komissarchik <[email protected]<mailto:[email protected]>> Reply-To: Cross project issues <[email protected]<mailto:[email protected]>> Date: Monday, 29 July, 2013 6:35 PM To: 'Cross project issues' <[email protected]<mailto:[email protected]>> Subject: [cross-project-issues-dev] Are too many packages actually hurting Eclipse? There are twelve packages currently listed on the downloads page, not counting the promoted ones. Are so many packages actually a benefit to users? We try to define packages based on developer profiles, but real developers rarely fit a profile. One of the most common complaints that I have seen on forums are related to difficulties in getting an Eclipse installation that has all the pieces that the developer requires. The ironic thing is that we go through a lot of trouble to define a common repository with components that are known to work with each other, but then fragment the result into a dozen different packages. Would user experience be better if there was only one Eclipse package on the main download site that had pretty much everything that’s in the aggregated repository? Some of the reasons for not doing that… 1. The package would be too large. With modern download speeds, I suspect most users would rather wait a few minutes longer for Eclipse to download than spend time later trying to figure out how to install the missing pieces. The disk space difference is also inconsequential these days. 2. The users prefer to not include pieces in their installation that they don’t use. I can see that being the case for some advanced Eclipse users, but I don’t believe this holds true across the user base. I suspect that most users would rather spend time on their development project than tuning their Eclipse installation. 3. Too many plugins in one installation leads to poor user experience. If there are problems like that, we should be identifying and fixing them. Thoughts? - Konstantin
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
