To me there are several reasons to the success of the distros over our update site. (I will just name two that I find relevant to this discussion, but obviously there are many others)
First distros are more inclusive than the Ganymede update site as you can install from them plug-ins not developed at the foundation.
Second because we have still not been able to break down the project silos in the way we are categorizing the content of our update sites, thus making it non-obvious for people to find something. Note that with p2 the situation is a bit better since the repo content can be filtered by the user, but still good categorization is key to consumption.
Bjorn Freeman-Benson ---04/29/2008 04:34:20 PM---Ganymede people,
Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>
"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>, Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
04/29/2008 04:34 PM
[cross-project-issues-dev] Heresy mark II (summaries and replies)
Some history (as I see it):
1. Originally the annual simultaneous release was all about coordinating releases. Just that, nothing more: coordinating the releases so that all the projects could release on the same day.
Hence my proposal that we don't need the Ganymede update site:
2. Originally (pre-Callisto) our goal was to have a single update site that merely *referenced* the existing project update sites. No file copying, no archiving, no building - just references so that our testers could point their update manager at a single update site url.
3. Using references in the update site did not work for technical reasons (the update manager couldn't handle it) so we went with a cobbled together single update site that copies the relevant files from the existing project's update sites.
4. This single update site has caused a number of problems including the user facing problem of having two updates site for each project: the central one and the project one. Which one does he or she get updates from? ... And there are all those update manager-related bugs where the setup hasn't worked for the simultaneous release for one reason or another (can't find required features, incorrect packing, etc.)
5. End users found/find the whole list of technical features on the central update site confusing - they've said so in bugs and blogs. Thus we started a "packages" program to provide simplified end user distros. The packages have been a pretty solid success (they account for over half of all downloads).
6. Serious adopters (companies building products on top of Eclipse projects) use the project distros or even the project sources rather than the central update site - or so I understand.
1. Not a good user solution
The reaction from you all has been mixed:
2. Packages are a better user solution
3. The central update site is work to maintain
4. Adopters don't use the central update site
1. Some agreement - that the goal of the simultaneous release was to synchronize the version numbers.
Specific responses (from me):
2. Some statements that the effort in building the update site is beneficial - although I don't see it, so I'd really like whoever said that to elaborate on why taking existing update sites and copying the files to a single update site provides any benefit. The reported benefits (finds conflicts) should be happening by the individual project build scripts, yes? And just copying the files to the same place doesn't do any cross project testing, which would be the key advantage anyway.
3. Some statements that users want to have a single place to find all the projects and that users won't go to the project specific pages - this is perhaps the best argument, but I counter it early by pointing out that the update site wasn't a good end user experience and that systems like Yoxos or Cloudsmith were a far better end user experience and so why don't we just use something like that? Especially when someone writes "start with package X and mix in feature Y" - those other tools do it so much better than our central update site.
4. Some statements that the sheer act of building a common update site is what forces us to work together - an interesting argument, although I'd rather see a situation where we driven by value to our consumers (adopters and end users) rather than by the act of copying files to a central location. The Ganymatic does not run any tests, nor does it attempt to load all the plug-ins into memory at the same time, nor any of the things that verify that things work together. It just copies files.
5. One statement that, in effect, said that we need a common build system for Eclipse projects so that we run a consistent set of tools (indexers, etc) on the binaries.
- "That is, if we can’t manage to aggregate a set of update sites into one, how do we expect end users to aggregate content from multiple sites into one Eclipse configuration" -- because they are two different activities: copying multiple update sites into one update site is different from using multiple sites to build an Eclipse instance. Ganymatic does not attempt to load all the plug-ins nor does it run any tests. The end users care about those issues, not whether all the files live in one directory or ten.
- "I meant the user selecting a subset of all Ganymede features...say, EMF core, DSDP-TM, Buckminster, and ECF...but not any/all of the other features in Ganymede. With the Ganymede update site that's via a single update site, rather than 4 update sites. " -- better yet, let's use a technology that's built for doing exactly that, e.g., Yoxos or Cloudsmith or ...
- "without a Ganymede update site I don't see that there is much about Ganymede to promote." -- well, there are the end user packages (>50% of our downloads) and there would be the Yoxos or Cloudsmith or other install technology that actually works well for the end user...
- "I'm not familiar with Yoxos or Cloudsmith" -- I urge you to go try one of them before replying further.
[end of message] _______________________________________________
cross-project-issues-dev mailing list