Igor, It almost sounds like you are asking "why harm is there in everyone releasing whenever they they are ready to, instead of doing it simultaneously", so I may not understand your question, but ... lack of understanding never stops me from giving an answer :)
Two constraints we try to meet are to a) make sure the mirroring system is well populated before making things visible (it takes 24 to 48 hours to be moderately populated, and a week to be fully populated) and b) make sure things are "simultaneous" so users can get a "matching set" of everything, once they install or upgrade to Juno. To give a slightly fictional example, In the past, people would sometimes open bugs on a Friday saying something like "they tried to update to next release of WTP, but got an error message that <EMF, GEF, Platform, or JDT, version such and such> could not be found ... and the answer to the bug was always "well, you have to wait till the release date of Wednesday", or similar). Now, you may be thinking of cases where projects never expose their own project's repository "to the public" and simply point their users and adopters to .../releases/juno ... and in such cases, the project's repository exists only to provide input to the aggregator, then I would say you probably could publish your artifacts "for real". But, not sure how many project's do that and hope if they do "publish early" they are confident no one in "general public" access it directly, or else some pre-req might not yet be ready or visible ... or might "overwhelm" download.eclipse.org with requests, instead of off-loading some requests to mirrors. I hope some of those answers might address what you are asking. If not, please ask again. Thanks, From: Igor Fedorenko <[email protected]> To: [email protected], Date: 06/13/2012 07:37 AM Subject: Re: [cross-project-issues-dev] Managing repositories referenced by simrel .b3aggrcon files Sent by: [email protected] No, I mean publish artifacts for real, with p2 metadata and everything needed to reference them from b3 aggregator. -- Regards, Igor On 12-06-13 7:33 AM, Dennis Hübner wrote: > Am 13.06.2012 um 12:49 schrieb Igor Fedorenko: > >> What harm in uploading last RC build to the final release location >> before 6/25 (or whatever the date is)? > > There is no harm, as long as the artifacts are hidden. > > Best regards, > Dennis. > >> >> -- >> Regards, >> Igor >> >> On 12-06-12 11:38 PM, David M Williams wrote: >>> It is important to make sure the b3aggrcon files point to something that >>> allows a "quick last minute rebuild" to be performed, if needed ... but >>> beyond that, there's no specific rule or guideline about how or when to >>> do it ... I think it depends on each project's (or release engineer's?) >>> confidence in make the a quick, seemless, highly reliable transition. In >>> other words, some projects update the b3aggrcon file to point to final >>> locations, and remove the old locations, before the release date ... >>> others leave the old in place and don't change the aggrcon file until >>> after 6/27 "just in case. But, then they should shortly after the >>> release. >>> >>> To summarize ... or repeat ... >>> >>> It is fine to update the b3aggrcon file during quiet week, to point to >>> an equivalent (final) repo if you'd like to do it "early" so you can get >>> rid of "old" copy. Ideally, those that do this, would use the "Validate >>> Aggregation" function from their own local b3 aggregator editor to make >>> sure there are no typos or anything. >>> >>> It is important to make sure the b3aggrcon files point to something that >>> allows a "quick last minute rebuild" to be performed, if needed. >>> >>> HTH >>> >>> >>> >>> >>> From: "Konstantin Komissarchik" <[email protected] >>> <mailto:[email protected]>> >>> To: "'Cross project issues'" <[email protected] >>> <mailto:[email protected]>>, >>> Date: 06/12/2012 10:58 PM >>> Subject: [cross-project-issues-dev] Managing repositories referenced by >>> simrel .b3aggrcon files >>> Sent by: [email protected] >>> <mailto:[email protected]> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> I have a question regarding proper strategy for managing repositories on >>> the download server that are referenced by simrel .b3aggrcon files. >>> >>> I just updated Sapphire contribution to reference [1], which is the >>> final contribution but we aren’t officially calling it final yet. Per >>> Final Daze document, on 6-25, I will copy this repository to [2] to make >>> the release official. Then I’d like to clean up old 0.5 pre-release >>> downloads. How do I safely do that since RC4 is still referenced by a >>> .b3aggrcon file? Since further aggregator builds aren’t expected, do I >>> update .b3aggrcon file on 6-25 to point to [2] and remove RC4 download? >>> Do I wait until after 6-27 to do this? >>> >>> Thanks, >>> >>> - Konstantin >>> >>> [1] : _http://download.eclipse.org/sapphire/0.5.0.RC4/repository_ >>> [2] : _http://download.eclipse.org/sapphire/0.5.0/repository_ >>> >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> [email protected] >>> <mailto:[email protected]> >>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>> >>> >>> >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> [email protected] >>> <mailto:[email protected]> >>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> <mailto:[email protected]> >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
