openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <>
Subject Re: Question about binary upload process
Date Thu, 08 Sep 2016 22:31:27 GMT
Patricia Shanahan wrote:
> we have a lot of binaries to upload.
> Could someone with experience or knowledge of the process tell me a bit
> about how it is done, how long it takes, and what, if anything, it costs
> ASF?

Sure. This changed just days before 4.1.2, but it still holds.

1) You create the binaries. These might be created by different people 
too. At the end, you have a few dozen Gigabytes. Note: this must be done 
for every release candidate; we had 3 for 4.1.2; I recommend choosing 
things/issues wisely so that 4.1.3 can aim at having only 1 RC (i.e., 
getting the first one right).

2) Whoever is in the best position to do so, uploads the binaries to the 
ASF. This can be done also by multiple people, who upload to different 
subdirs here:
For all the 4.1.2 RCs I did it alone, from a good connection, and it 
took an absurd number of hours since the connection was slow on the ASF 
side. Speed may be better now (honestly, I don't see how speed could be 
worse). A good trick was to upload artifacts to and 
commit from there: this was much faster, but Infra has now disallowed it 
by (almost) decommissioning

3) Only the final one must be uploaded to SourceForge; I copy/paste from section 
"Upload builds to mirrors". "Volunteers: Andrea Pescetti - Copy requires 
just a few hours, with the normal rsync instructions shown at 
(project name is openofficeorg.mirror). Set new files as "Latest 
Version": done by Marcus Lange see "; you 
probably don't have admin permissions for the OpenOffice project on 
SourceForge, but all other members can give you admin access. Just ask.

4) On dist, moving from dev to the actual tree is just a matter of svn 
mv. This at least is very fast.

5) Costs: we use standard ASF infrastructure here, and our own time. 
Costs for the ASF are just the ordinary running costs that they wpuld 
have even if we don't release anything. Waste of storage space due to 
storing in SVN hundreds of GBytes of non-approved RCs was not an issue 
last time I spoke to Infra about this.

Let me add that Infra provided good support for 4.1.2, especially for 
RC1 when we needed some significant configuration changes to accommodate 
our RC. These changes are now permanent.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message