[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Notes from a Heretic: Why do we have the Ganymede update site?

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]