| RE: [eclipse.org-planning-council] RE: [cross-project-issues-dev]Heresy mark II (summaries and replies) |
|
Hi Bjorn,
I think I see the point in your theory, that copying bits
from location x1, x2, x3...
to location G (for ganymede) should be equivalent to
pre-populating information
about location x1, x2, x3, ... in the base Eclipse
downloads (SDK, packages).
In the case of Ganymede, however, we're not only copying
but also filtering:
the project update sites x1, x2, x3... are typically
organized in a different way
than Ganymede, because their job is UPDATING rather than
GETTING AN
INITIAL INSTALL. Because of this, those project update sites
typically
So, while I'm not totally opposed to your theory, my word
of caution is that
if we want to go this route, projects will likely need to
have two site.xml
themselves -- one for their main update site, the other for
"initial install via
update manager".
Which is, essentially, same work as before (maintaining
site.xml and site.sc).
And, deprives us of the ability to do more fine-tuning with
the categorization,
since categorization will be strictly per-project only.
Therefore:
-1 for removing the Ganymede
site
+1 for investigating turning Ganymede into a P2
Metadata Repository
rather than holding all
the verbatim bits
I'm in favor of investigating using more P2 features for
the Ganymede site
instead. Perhaps there are possibilities of making the
Ganymede site more
of a "metadata Repository" only, that contains the
assembled pointers
to the project update sites only but not the real files.
This would relieve
us from actually copying any bits, and would save us in the
gigabyte
range of diskspace on both download.eclipse.org and all the
mirrors.
Provided that mirror are set up for mirroring all the
project update sites,
and not just Ganymede alone. But even this can be solved by
P2 because
it does automatica mirror selection
anyways.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
|