Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-planning-council] Heresy mark II (summaries and replies)

Title: New Page 1
Ganymede people,
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.
  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.
Hence my proposal that we don't need the Ganymede update site:
  1. Not a good user solution
  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
The reaction from you all has been mixed:
  1. Some agreement - that the goal of the simultaneous release was to synchronize the version numbers.
  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.
Specific responses (from me):
  • "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.
- Bjorn
--
[end of message]

Back to the top