[atlas] state of the source code repository and releases [was: upgrading an original soft probe]

Hello Michel,


thank you for clarifying. Can we bring those very useful informations
(master is production ready; releases are tags based on master
divisible by 10, tags non divisible by 10 need to be ignored) into
README.rst? Are you accepting PR's or patches?

I think what would also help is if you would create a github release
with a source tarball. We are only looking at tags because of the
absence of GH releases.
Formal announcements of new production releases on this mailing list
would also help (basically everyone involved with RIPE atlas).

It's important to demystify the repository and release process, and
for this information not only be in one old mail in the list archives.


FWIW OpenWRT is already packaging atlas, it seems to work and the
response on packaging related bugs [1] is also very fast [2].



Thanks,

Lukas


[1] https://github.com/openwrt/packages/issues/20338
[2] https://github.com/openwrt/packages/commit/dc39bbef1452047eb22d78445e30644d2e1d22dd

On Thu, 8 Jun 2023 at 11:29, Michel Stam <mstam at ripe.net> wrote:
>
> Hi Lukas!
>
> Sorry for the delay in response, I was off for a few days and for some reason your mail got buried beneath a pile of other mail.
>
> Let me give you a bit of a background;
>
> About a year or so ago we set up a CI/CD pipeline for the software and hardware probes. The intent being that the software would be built by a clean platform every single time a commit was tagged for building, or if any of the major branches were updated. This all happens from an internal repository that is not publicly accessible.
>
> Somewhere around that time we also started with a new development strategy.
>
> A master branch which contains production-ready code. This is the code that users can deploy on their own setup, and it is also the code that the RPMs and the hardware probe firmware will be built on.
> A testing branch on which the master branch is essentially a pointer. The testing branch contains code that is being readied for the next production release
> A devel(opment) branch that contains code which is by its nature feature complete, but may not be fully tested yet. This code is merged into the testing branch upon completion and unit testing.
> Ticket branches that run off the development branch and contain features that may or may not work
>
>
> Out of all of this, only the tags and master branch pointers are automatically synced from the internal repository to the GitHub repository. This is by intent to discourage people from deploying code which is not feature complete. For sake of transparency, as well as convenience, this code is visible. Well spotted! :)
>
> The versioning is your next implied question- any number divisible by 10 is a production release (5060, 5070, 5080). Any other number is either a development or a testing release. I would recommend to use the master branch or any tag which is divisible by 10, which in essence would be a (previous) production release.
>
> As to decreasing numbers. At the time there were two people working on different features at the same time, some of which we were both testing on different probe platforms simultaneously. One was working on 5083 the other on 5081/2. Ugly, yes. I believe I was restructuring for the version 3 hardware probe at that time.
> Ideally we would sync only the release tags and not the development tags, but unfortunately that is not how the internal repository (Gitlab) works.
>
> The current released version is 5080. I’m working on the next release as we speak, which will include a restructure to accommodate providing packages to the RHEL repositories. I’m interested in talking to debian distribution maintainers who are willing to help do the same for Debian. OpenWRT is also something I’ll be looking at.
>
> Short and simple. Master contains the latest production code. Use it in good health :)
>
> Cheers,
>
> Michel
>
> On 4 Jun 2023, at 20:03, Lukas Tribus <lukas at ltri.eu> wrote:
>
> Hello Michel,
>
>
> On Sun, 12 Feb 2023 at 22:51, Michel Stam <mstam at ripe.net> wrote:
>
>
> Hello Randy,
>
> We are currently actually looking at providing packages for other distributions, through
> the regular repositories of the distribution. However that means we have to work pieces
> of the software probe to comply to distribution standards. I cannot guarantee right now
> whether Debian will be provided, but this is something I would personally like to see.
>
>
> For third party package maintainers and users willing to compile from source:
>
> What is the currently released version of the atlas-software-probe?
>
> HW probes seem to be running 5080.
>
> On the git repository we have the following tags:
>
> 2022 Sep 19: 5080 was tagged
> 2022 Nov 30: 5083 was tagged
> 2022 Dec 9: 5082 was tagged
> 2023 Feb 24: 5081 was tagged
> 2023 Feb 28: 5084 was tagged
>
>
> Is 5080 the current release, which HW probes are running, and the
> newer tags in the source code repository should be ignored?
> Is 5084 the current release, but HW probes are lagging behind?
> Why did we see decreasing versioning tags from November to February?
> Where can a third party package maintainer (or a user compiling from
> source) find authoritative information about what the latest atlas SW
> probe actually is?
>
> There is only a single branch in the git repository, which is master.
> However while the 5080 tag seems to be in the master branch, the newer
> tags are not, so I guess that means 5080 is indeed the last properly
> released version.
>
>
> But I really don't like to guess and I don't see how anyone not
> directly involved in the SW development of the probe would be able to
> package it considering the ambiguity in the source code repository.
>
>
>
> Thanks,
>
> Lukas
>
>