On 1 September 2013 14: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 > >>> 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. > > 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? > > 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. > > 2) We need to make sure SourceForge is not rsyncing from /dist and > mirror the 4.0.0 removal. > > And I assume 4.0.1 goes to archive then? > > -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.
Unfortunately, I think there are too many disadvantages. The sigs/hashes are not mirrored. So they would be updated immediately, but the mirrors would still have old binaries. Even if they were mirrored, it would be impossible to ensure that the 4.1.x sig/hashes were updated at the same time as the binary. Mirrors may end up with two copies of the file, one for the link, and one for the actual file. I'm not sure if this is a problem with the rsync protocol or the rysnc settings our end or their end. Also what happens when you want to release 4.2.x? IMO a better solution would be to split the download so the core code (which is by far the biggest chunk) is only produced for a single language (or none) for each OS. The user also has to download whichever language packs they want. This could potentially be done automatically with a small installation loader that then downloads the core code and the chosen language pack. SInce the loader would be tiny (in comparison) it would be OK to produce customised versions for all the release combinations. Maybe multiple downloads can even be done with HTML these days; or maybe the server could be given a special URL that identifies the OS and language and it generates a download containing both. This could also have major advantages for development as well. > -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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
