9 Dec
2013
9 Dec
'13
2:09 a.m.
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