On 9/1/13 4:45 PM, janI wrote: > On 1 September 2013 15:31, Rob Weir <robw...@apache.org> wrote: > >> On Sun, Sep 1, 2013 at 5:42 AM, janI <j...@apache.org> wrote: >>> On 1 September 2013 11:27, janI <j...@apache.org> wrote: >>> >>>> Hi. >>>> >>>> I had a talk on #asfinfra today, regarding our upcomming 4.0.1 release. >>>> >>>> Sync on mirrors takes about a week, and the mirror can in general not >> hold >>>> 4.0 and 4.0.1 >>>> >> >> Is this a change? The current published advice is that the mirrors >> take no more than 24 hours to sync: >> >> https://www.apache.org/dev/release-publishing.html#distribution >> > > no actually not, the problem is the size of our distribution, with 4.0 it > took 8 days and one Chinese mirror has not updated fully yet. > > >> >>>> Therefore the current suggestion is to >>>> a) remove 4.0 from mirrors GA - 1week = 12 september >>>> b) update 4.0.1 to mirrors GA = 19 september. >>>> >>>> The downside is that mirrors will have the 4.0 ready for download for >> upto >>>> a week. >>>> >> >> The problem is we don't know for certain a GA date a week in advance. >> We can just estimate. But as we saw with 4.0.0, a last minute defect >> can delay things by a week or more. >> > > We have a choice, we can wait until GA (as we did last time, where it took > several weeks after GA before downloads were in place), or take a chance. I > opt for the chance, I think it is important to have the mirrors in place > when we announce our release.
I think most of the downloads are going over SourceForge so having the mirrors a little bit later in sync shouldn't be a big problem. I would prefer one simple to follow approach. And the synch is done in a way that is suitable for the mirrors. A further question how do we count the downloads from the ASF mirrors or can we count them at all? > > >> >> So in practice this means that there could be more than a week where >> 4.0.0 is not on the mirrors. Maybe this is not a problem? >> > > I hope not, we loose some downloads, but hopefully the users will try again. > > >> >> The two things to watch out for (and you have probably already >> considered these, but I'll mention them just in case): >> >> 1) We should not remove the 4.0.0 hashes and signature files from >> /dist. These are referenced even when the binaries are downloaded >> from SourceForge. >> > > @henkp: can you make sure of that, please > >> >> 2) We need to make sure SourceForge is not rsyncing from /dist and >> mirror the 4.0.0 removal. >> > > I assume that will be the case. > >> >> And I assume 4.0.1 goes to archive then? >> > > If I remember right, we (andrea) have to move it to the archive (I presume > you mean 4.0). no, it goes automatically to archive as far as I know Juergen > > rgds > jan I. > > >> >> -Rob >> >> >>>> An alternative suggestion, is to rename 4.0 to 4.0.x on the mirrors and >>>> have a 4.0 symlink pointing at 4.0.x. >>>> >>>> That way, we simply replace the 4.0.x file, after GA, and mirrors do not >>>> have a time without a package. >>>> >>>> I personally like the rename idea, so can we do lazy consensus on that ? >>>> >>>> I have updated issue 6654, and Henkp is copied on this mail. >>>> >>>> rgds >>>> jan I >>>> >>> >>> Second try, sorry for the first mail. >>> >>> I had a talk on #asfinfra today, regarding our upcomming 4.0.1 release. >>> >>> Sync on mirrors takes about a week, and the mirror can in general not >> hold >>> 4.0 and 4.0.1 >>> >>> Therefore the current suggestion is to >>> a) remove 4.0 from mirrors GA - 1week = 12 september >>> b) update 4.0.1 to mirrors GA = 19 september. >>> >>> The downside is that mirrors will have the 4.0 ready for download for >> upto >>> a week (SF will be faster). >>> >>> For 4.1 we should consider an alternative way. >>> >>> Use 4.1.x on the mirrors and have a 4.1 symlink pointing at 4.1.x. >>> >>> That way, we simply replace the 4.1.x file, after GA, and mirrors do not >>> have a time without a package. >>> >> >> That's an interesting approach that could work. >> >> -Rob >> >>> I have updated issue 6654, and Henkp is copied on this mail. >>> >>> rgds >>> jan I >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
