Re: [cross-project-issues-dev] Managing repositories referenced by simre

[David M Williams <david_williams@xxxxxxxxxx>]

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 <ifedorenko@xxxxxxxxxxxx>
To:      
 cross-project-issues-dev@xxxxxxxxxxx,

Date:      
 06/13/2012 07:37 AM
Subject:    
   Re: [cross-project-issues-dev]
Managing repositories referenced by simrel .b3aggrcon files
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

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" <konstantin.komissarchik@xxxxxxxxxx
>>> <mailto:konstantin.komissarchik@xxxxxxxxxx>>
>>> To: "'Cross project issues'" <cross-project-issues-dev@xxxxxxxxxxx
>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>,
>>> Date: 06/12/2012 10:58 PM
>>> Subject: [cross-project-issues-dev] Managing repositories
referenced by
>>>        simrel .b3aggrcon files
>>> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
>>> <mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> 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
>>> cross-project-issues-dev@xxxxxxxxxxx
>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@xxxxxxxxxxx
>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev