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