From a non-technical point of view, this is necessary to give visibility to projects for which it does not make sense to either be an EPP package on their own, or would have to be included in every package (think things like ECF, SVN, etc...). Without the ganymede site, users could not discover all the diversity and they would have to known about things by word of mouth and site hunting.
>From a technical point of view, there use to be problems with update manager not necessarily finding the required features when they were spread among multiple sites and aggregating was good for this.
As for the management argument, I don't really buy it (but I don't have to do this management either) as people still have to manage multiple sites to separate the Release from the M, I or N builds made available on an update site.
Also, if we were not automatically adding the sites found in features, the ganymede update site would offer a very good control point to only make available to users things that have been tested together, rather than letting the user update to things as they become available without having been tested with the other pieces (for example, today I can find an update of the Eclipse Platform which had not necessarily been tested with the rest of Ganymede and could in turn break depending components in subtle ways).
PaScaL
Bjorn Freeman-Benson ---04/28/2008 01:40:49 PM---Ganymede Project Leads,
From: |
Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx> |
To: |
"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>, Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> |
Date: |
04/28/2008 01:40 PM |
Subject: |
[eclipse.org-planning-council] Notes from a Heretic: Why do we have the Ganymede update site? |
Ganymede Project Leads,
Let me open a can of worms and publicly ask why we have the Ganymede Update Site.
It seems to me that:
- For users, we have the Ganymede packages (http://phoenix.eclipse.org/packages/)
- If we have packages, why have a separate update site? The packages have all the update sites built in (via the feature.xmls).
- And if someone wants to add new functionality to their existing Eclipse, they will go to the project specific update site and get the latest bits.
- For adopters, we have the project downloads and update sites - why should we have a second update site for these?
- In fact, having a second update site just makes things more complicated because then "where do I get future updates? do I get them from the central update site or from the project update site? and why are there so many similar update sites listed in my Eclipse?"
- More complicated for project teams too, because then they have to maintain different site.xmls, feature.xmls, etc.
The original reason for the unified update site was because it was confusing for users to have to go here and go there and go the other place to put together a package. But now that we have packages, why do we need the unified update site? It seems to be extra hassle and complexity for everyone at no net benefit to anyone.
Comments? Opinions?
- Bjorn
--
[end of message] _______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
|