On Monday 09 of December 2013 00:23:20 Darrell Anderson wrote:
> Please let me clarify. Announcing availability in a press release
> would be by full package sets, not individual packages. For
> example, the initial press release would include all of the
> supported Debian/Ubuntu package sets and any other distro package
> sets that have been made available, such as those from Francois.
> The site web page contains the links for those full package sets.
>
> After that initial batch of package sets are uploaded and mirrored,
> and announced, then begin building ARM package sets. When the ARM
> packages are ready then issue another press release.
>
> Likewise with all package sets for other distros.
>

Armel packages are built for all versions of Debian distribution. Until they 
are completed, it is not possible publish packages for Debian distribution => 
Debian with such a scenario would not be in the first wave - it's not good.

The second problem is that during a complete rebuild may be discovered new 
problems that require not scheduled hotfixes. A similar situation was already 
in 3.5.13.2 - on several packages was moved GIT tag. Similar complications 
are now FTBFS on tqt3 and tdevelop.

> Something like this:
>
> 1st press release: ...full package sets are available now for
> Debian XX, XX, XX; Ubuntu XX, XX, XX; Fedora XX, XX. Build scripts
> are available for Slackware 14.0. Package sets for ARM are
> forthcoming.
>
> 2nd press release (whenever needed): ...full package sets are now
> available for ARM; OpenSuse XX, XX, Mageia XX. Build scripts are
> available for Slackware 13.1, 13.37, and 14.1.
>
> 3rd press release (whenever needed): ...
>
> The picture I'm trying to paint is we don't wait 18 or more days to
> start the release cycle. If the Debian and Ubuntu packages build
> quickly on the build farm, get those prepared first. Then focus on
> the next wave of package sets. Something like an 80/20 principle:
> Have 80% of the most needed package sets ready, then with those out
> of the way, prepare 80% of the remaining 20%. Etc.
>
> Darrell
>

Anyways, there are two separate problems:
1) rebuild all final packages - discussed above
2) Publish to the mirror � slow upload on master server

When publishing 3.5.13.2 most of the time was waiting for the completion of 
synchronization to mirrors.

In the case the packages on the master server published continuously, with 
increasing total volume will lengthen the time to synchronization => is 
completely out of control way to sending announces gradually.

In the case that the packages will be gradually published by individual 
distributions, then there would be a lot of slowdowns due to waiting for the 
completion of the synchronization mirrors for individual distributions.

Slavek