Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] An alternative to ?

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.
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Kim Moir
Sent: Donnerstag, 28. Februar 2008 22:08
To: Cross project issues
Subject: Re: [cross-project-issues-dev] An alternative to ?

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 have been problematic.  I don't know if this is still an issue.


"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>

"Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
[cross-project-issues-dev] An alternative to freezing ?

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...
* 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 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 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...

Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
cross-project-issues-dev mailing list

Back to the top