Indeed if you are doing an update based on a package
distribution. However people doing target management (not sure if that UI is
prepopulated with URLs, will check) or people who have, heaven forbid, bought products
based on Eclipse that do not come prepopulated with Eclipse URLs are not so
fortunate.
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer,
Doug
Sent: Tuesday, April 29, 2008 11:05 PM
To: Cross project issues; eclipse.org-planning-council
Subject: RE: [cross-project-issues-dev] Heresy mark II (summaries and
replies)
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jeff McAffer
Sent: Tuesday, April 29, 2008 4:59 PM
To: 'Cross project issues'; 'eclipse.org-planning-council'
Subject: RE: [cross-project-issues-dev] Heresy mark II (summaries and
replies)
- 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.
|