- 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.
These
points are valid but they are the implementation of a greater goal that was to
ease the lives of consumers. To make it easier for them to get a
consistent lineup of Eclipse function that at least was thought to work
together. I don’t recall ever liking the idea of sending consumers all
over eclipse.org to get what they need.
- "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.
First,
where the files live is not the issue as long as the end user only has to type
in one URL.
If
all Ganymatic does is copy files, how does it fail and why is it so much work
to run/maintain? That is an honest question. My assumption is that
if something that fails in Ganymatic it is somehow going to fail for end
users. I realize that the reverse may not be true (e.g., working in
Ganymatic does not necessarily imply it will work for the user) but some
coherence checking is better than none.
