>However, yes, publication time should be shortened - during the 
building 
>arm packages 
>may be published packages for other distributions, that not depend 
>on arm 
>packages (for example all Ubuntu versions).

Then let's do that?

>Sending one announcement after tagging the sources in GIT and then 
>after every 
>publishing binary package to me does not seem like a good idea. 
>Immediately 
>after announcement users will ask just for binary packages.

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.

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