Re: [cross-project-issues-dev] An alternative to freezing download.eclip

[Kim Moir <Kim_Moir@xxxxxxxxxx>]

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