29 Jul
2018
29 Jul
'18
6:58 p.m.
On Sunday 29 of July 2018 12:15:07 Mike Bird wrote:
On Sun July 29 2018 02:09:22 Slávek Banko wrote:
Hi Mike,
do you remember when I started preparing the packages, which then resulted in
the maintenance v3.5.13.x branch? Small reminder:
http://trinity-users.pearsoncomputing.net/?0::2776
Do you remember my 'axis' repository on QuickBuild? This repository met your
proposal - it was on the primary server - on QuickBuild. However, placement
of this repository brought a combination of all the disadvantages that it
could have:
+ although the repository is on the primary server, but under my account on
QuickBuild == repository is not signed by the official TDE key, but the GPG
key corresponding to my QuickBuild account
+ only official repositories are published on mirrrrors == all access to
the 'axis' repository causes total bandwidth load on the primary server - all
users constantly complained about very slow downloading of packages - if the
master server was unavailable, the repository were not accessible at all
+ on QuickBuild at that time often were situations where builders were stuck
and repositories were inconsistent - users could not download and install
packages or broke their machines
+ adding support of new Debian / Ubuntu distributions on QuickBuild is always
a challenging operation - requires local mirror of distribution == a lot of
space, therefore adding support for new distributions was slower
Creating a completely independent Preliminary Stable Builds repository (both
building and repository management) was therefore a significant benefit for
the users but also for the release of new TDE releases.
Some time ago, I and Tim agreed to place Preliminary Stable Builds repository
directly to the redirector. As a result, this independent repository gained
more official status ... and at the same time raised the questions that we
are currently discussing :)
Because I do not want the mail to be too long, now I will finish this part and
I will continue with the next mail.
--
Slávek
As I mentioned above, all official repositories
(signed by the official
Trinity key) are managed on QuickBuild. As I explained in previous
emails, Preliminary Stable Builds are created independently of
QuickBuild - independent builders (used pbuilder on my builders),
independent repository maintenance (used reprepro on my server).
That's why PSB repositories simply can not be signed with an official
Trinity key that is integrated with QuickBuild. I could create some
general GPG key for signing repository instead of my personal, but it
would still be a key other than the official Trinity key. So it seems
like a futile change.
Regarding the propose to rename from 'stable' to 'testing' builds, this
change is not possible. Existing Preliminary Stable Builds are built on
a 'stable' branch (now r14.0.x) == this is preliminary packages for the
next maintenance relase - therefore 'stable' in the repository name.
Additionally, the second repository named Preliminary Testing Builds has
already been prepared. This second repository is built on a 'master'
branch == this is preliminary packages for the next major release, which
rightfully deserves the naming of 'testing'. The official announcement of
this 'testing' repository can be expected soon.
Hi Slávek,
I am not yet understanding why we have so much duplication. Why is there
not a "testing" release in the main repository instead of a having a main
repo and a DEB PSB repo and a RPM PSB repo in different locations and
using different tooling? (And soon in addition a new DEB testing repo?)
I understand that PSB updates every two hours whereas the primary mirror
currently checks for updates three hours after the completion of the
previous run, but I could change the three hour delay to a ten minute delay
without adversely impacting Tim's bandwidth. What is the average volume
(GB) of DEB PSB updates published per day?
The standard single Debian repository structure is well understood by all
concerned. It reduces the number of downloads and upgrades needed for
new minor releases and generally provides a smoother and more efficient
transition from testing to release. Indeed Trinity successfully used a
single repo incorporating trinity-nightly-builds for many years.
--Mike