> You mentioned "shortly before/after the
final common aggregation build"... > Do you mean RC4 (RC4 + 1, in my case) ?...
Is there any other specific date for this?
The best time for final promotion-of-bits is during the
first part of "quiet week".
RC4 ends 2/18, the builds are done and turned off, and
the official release is 2/25.
The time in between is for promotion of final bits, extra
testing, preparation of webpages, etc.
It is assumed (or, required) that if you promote your
bits early in the week, that they remain "invisible" until the
release date of 2/25. But, having the bits in their final "downloads"
location make it possible for mirrors to duplicate the (large) data over
several days in preparation for the release. By "invisible",
it is mean these final bits are not listed on any end-user (final) download
pages, and are not "seen" by p2. For p2, this means the artifacts
themselves are put into their final location, but the content.jar/xml is
not; or, better, the composite repo files are not updated until release-day.
I have heard of (small) projects, that don't have the ability to do this
multi-step promotion, to just promote their final stuff on the morning
of 2/25 and make it visible at the same time. This is ok as long as there
is just a few small projects doing it ... but big mirror hogs like the
Platform, CDT, BIRT, or WTP, must be more careful. (And, really, I don't
know if CDT or BIRT are big mirror hogs ... just thought I'd throw in some
big sounding ones for illustration. :)
> mirrorsURL attribute for their artifacts repo,
they should have "download stats" attributes >> I don't have any knowledge about what to
do with our final release repository... Do you know any wiki page to look
into this topic ? Any tool/script available to do it ?.
I had to do a search of cross-project
list to refresh my memory (I did that, by going to the archive
view of this list, and typing
'downloadstats' in the "Google custom search" box there ... very
I eventually found where download
stats are documented from p2 point
of view and some conventions that should be used are also discussed
in previous threads on this list.
I don't know if these were ever captured on a wiki somewhere ...
if not, it'd be a nice contribution (hint hint) :) ... but
one of the important ones is no one should track stats on ALL their artifacts.
It could overly tax eclipse servers. Just pick a few key features to track,
is the advice.
'mirrorsURL' likewise is documented
somewhere in p2 documentation.
I remember in some bugzilla somewhere,
at some time, people were discussing how badly we needed a common tool
to be used to programmatically edit downloadstats fields and the mirrorsURL
attributes, but my memory is that no one wanted to "own it" and
it end with several example "apps" attached to the bug, and everyone
just rolled their own from there, as far as I know. It is likely on cross-project
Hope that answered a few more of your
questions! Keep 'em coming!