Ganymede people,
Some history (as I see it):
- 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.
- 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.
- 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.
- 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.)
- 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).
- 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:
- Not a good user solution
- Packages are a better user solution
- The central update site is work to maintain
- Adopters don't use the central update site
The reaction from you all has been mixed:
- Some agreement - that the goal of the simultaneous release was to
synchronize the version numbers.
- 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.
- 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.
- 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.
- 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]
|
