John,
You raise two points:
I guess this question comes down to
whether we expect the EPP packages to satisfy the vast majority of
users.
Packages are like the table d'hoteat a restaurant, whereas the
Ganymede
update site is like ordering a la carte. Many users will be
satisfied
with the packages, but other more discerning users want greater
flexibility
to pick and choose among the available offerings.
I think ordering a la carte would be
very difficult without the common update site.
(1) I would say "ordering a la carte would be difficult without *some
common mechanism*" but it doesn't have to be an update site. For
example, in a previous email I mentioned Yoxos and Cloudsmith as nice
end-user a la carte tools. (I wonder if that email did not get out
because I haven't seen any comments about my suggestion.)
The common site also gives us a good
control point for staging and running tools such as site optimizers and
the EPP packaging scripts. For example we would like to run a script
over
the Ganymede site in 3.4 to inject p2 metadata into it, which optimizes
performance for users of the latest Eclipse platform release. Without a
common site, each project would have to run such tools independently.
Also,
it gives one site for our mirrors to replicate that covers all the
simultaneous
release projects.
(2) That's actually a good argument for having only one update site,
period: an "all of Eclipse" update site. Or a good argument for
providing those tools in an easy-to-use form for all projects. But it
doesn't seem to me to be a good argument for a Ganymede update site
because a Ganymede update site would only be a subset of all projects.
So we should either have only one update site (thus ensuring that the
tools are run) or good tools (thus ensuring that the tools are run).
- Bjorn
--
[end of message]
|