On Sun July 29 2018 02:09:22 Slávek Banko wrote:
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