[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cross-project-issues-dev] An alternative to freezingdownload.eclipse.org ?
|
Right,
my strategy does not work for the update site so freezing
the
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
not
affected. Provided that you have an internal
"milestones"
update site for the Europa-o-matic to
consume.
Cheers,
--
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.
Kim
"Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
02/28/2008 11:31 AM
|
Please respond
to
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx> |
|
|
To
| "Cross project issues"
<cross-project-issues-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| [cross-project-issues-dev] An
alternative to freezing
download.eclipse.org ? |
|
Hi all,
being in Winter Maintenance endgame, this is probably
not
the best time for a new suggestion, but it recently hit me
that the
way we currently work with renaming builds seems
less than
optimal:
* release candidate builds are announced with their
old
names plus information what the new name will be
* release
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
up changes
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
well:
* The overall TM Downloads Page is a dynamic php
page
(stolen from GMF, thanks Rich :-) which lists
available
downloads
http://download.eclipse.org/dsdp/tm/downloads
*
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
BUT
package.properties is not put there (or renamed to
a
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
the download
page until that single little file "package.count" is
added
or renamed.
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
for
future milestones and releases? If you think there is a flaw
in this
procedure, just let me know...
Cheers,
--
Martin Oberhuber,
Senior Member of Technical Staff, Wind River
Target Management Project
Lead, DSDP PMC
Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
cross-project-issues-dev
mailing
list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
