Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
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
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
-
Darrell Anderson -
Slávek Banko