- 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.
