RE: [cross-project-issues-dev] An alternative to freezingdownload.eclipse.org ?
my strategy does not work for the update site so freezing
servers makes sense for that one.
But that's only the step where the "Coordinated Staging"
update site goes live.
The step where project contributions are accumulated is
affected. Provided that you have an internal
update site for the Europa-o-matic to
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Yes, this sounds like a good
approach. The only downside I see with this strategy is that the update
site is available early without having any mirrors. I know that in the
past, when we have uploaded a maintenance release without freezing, the number
of update jar requests to eclipse.org have been problematic. I don't
know if this is still an issue.
02/28/2008 11:31 AM
Cross project issues
|"Cross project issues"
alternative to freezing
being in Winter Maintenance endgame, this is probably
the best time for a new suggestion, but it recently hit me
way we currently work with renaming builds seems
* release candidate builds are announced with their
names plus information what the new name will be
engineers patch their build scripts to ensure
that their future
builds will have information where
to get proper prerequisites...
based on information
about the future...
* download.eclipse.org is
frozen for mirrors to pick
all this requires quite
a bit of manual work, and seems
like an awkward workflow.
So what is
my suggestion? - Here is what's been working
find for us in DSDP-TM and
I'm wondering whether this might
be appropriate for other projects as
* The overall TM Downloads Page is a dynamic php
(stolen from GMF, thanks Rich :-) which lists
Downloads are only listed when PHP finds them "proper",
i.e. a magic
little file "package.count" must be there
* When we're done with a release
candidate, it gets its
final name right away (R-2.0.3-200802251530)
and is put
in its final location
package.properties is not put there (or renamed to
different temporary name).
--> That way, anybody who
"knows" (via cross-project mailing
list for instance) where the
release candidate is, can
already download it. This includes the
mirrors, of course.
--> BUT ordinary users still won't see the bits on
page until that single little file "package.count" is
That way, everything goes into its right
place from the beginning,
dependent projects can consume it from the right
place, and there
is no need for server freezing. Would that be an option
future milestones and releases? If you think there is a flaw
procedure, just let me know...
Senior Member of Technical Staff, Wind River
Target Management Project
Lead, DSDP PMC