I wonder if we should bother to enable discussions on this repo, as swapping issues and discussions is pretty easy, and would allow to discuss ideas before moving them to real issues.

That would generate an extra forum like for LibreTime, duplicating discourse and I don't know if we have a use for this. I'm not using discourse a lot though, it feels more like we could use a dedicated place to discuss financial/organizational topics without newcomers asking for help (hope this doesn't sound mean towards newcomers).

Or maybe I didn't find any dedicated place were such discussion can happen appart from the (closed source) admin team panel, and the dev topic category on discourse.

@hairmare Hey, I would like to move the open letter to the Airtime community into the LibreTime repository.

https://gist.github.com/hairmare/8c03b69c9accc90cfe31fd7e77c3b07d

Is that ok for you ?

It is causing a lot of HTTP 429 with our link checker, and was thinking about moving it under the libretime umbrella for some time now, as part of the history documents.

According to libretime/libretime#1713 this repo had a bigger purpose as only storing a code of conduct.

So to make this idea happen, we should rename this repo to something more generic, like 'org' or 'meta' or something else, I don't have any specific idea.

Hello,
it caught my eye that libretime has a code of conduct. And ever more so that it is based on contributor covenant. Do we really need this sjw crap?
Seriously, what has gender identity, race, religion, sexual identity and orientation to do with development and free software?
Please rethink this decision.
Thank you.

We need access to https://hub.docker.com/u/libretime.

From what we heard, @ned-kelly created it. We are awaiting an answer.

Ref: #7 (comment)

Related to #7
This ticket track the transfer of the domain name from @hairmare's domain name provider to Gandi.net.

See #7 (comment)

Describe the proposal

Context libretime/libretime#1497

I propose to provide a testing infrastructure for the project and a demo to the public. I will try not to elaborate too much on the technical details but they involve how much money goes into it.

In terms of testing I think we only need 2 different distributions, each with the latest system of both Debian and Ubuntu (Bullseye and Focal), this means 2 different devices to pay for. Once we fully support containers, we should only need a single device running different distributions inside containers.

In terms of a demo, having a second Libretime stack installed next to the testing installation should be good enough. I consider the demo a lower priority compared to the testing infrastructure.

Management of these devices should be handled use infrastructure as code, so changes can be reviewed and approved by maintainers. Transmission to future maintainers should also be easier.

These devices could be used for other purposes.

Cost breakdown

This depends on the platform offering these servers:

• Hetzner
  2 x CX11 3,49€ (no VAT) / month

• [Add providers if you have a better solution]

I don't know how far we need to pan for the funding of this, if we plan yearly or every 6 month.

Involvement

I help to maintain LibreTime and expect that continuous testing of the deployed services will make the development cycle faster. The demo is intended to bring the project to the public in order to reach more people and grow the community.

PyPi now supports organizations - https://blog.pypi.org/posts/2023-04-23-introducing-pypi-organizations/ and we can request an organization for LibreTime. This would allow us to eventually upload Python packages to PyPi (e.g. the eventual API package) without needing to share credentials for a single user.

Should I go ahead and request an organization?

I am unsure if a document listing the possessions and ownership has already been drafted, but it makes sens to make it open source and easily accessible.

I am thinking about things like the domain name 'libretime.org', who owns it, and how much does it cost, this will probably help us maintain the org on the long run. (I am thinking about this mostly because of the whole mess happening around the celery project and it's domain name). Same could go to the discourse / mattermost instance.

This might be a small part of the "spending" document that @paddatrapper is writing.

In the following of #3 and libretime/libretime#1277 I propose to rename the master branch to main.

This should be easier on this repo than on the libretime repo.

Once #18 is completed, we can setup some email address for LibreTime.

Such as the security email address or a shared alias for basic administration.

We received a mail from docker hub warning us that they are sun-setting the free team organizations:

Docker is sunsetting Free Team organizations

Free Team organizations are a legacy subscription tier that no longer exists. This tier included many of the same features, rates, and functionality as a paid Docker Team subscription.

After reviewing the list of accounts that are members of legacy Free Team organizations, we’ve identified yours as potentially being one of them.

If you own a legacy Free Team organization, access to paid features — including private repositories — will be suspended on April 14, 2023 (11:59 pm UTC). Upgrade your subscription before April 14, 2023 to continue accessing your organization.

If you don’t upgrade to a paid subscription, Docker will retain your organization data for 30 days, after which it will be subject to deletion. During that time, you will maintain access to any images in your public repositories, though rate limitations will apply. At any point during the 30-day period, you can restore access to your organization account if you upgrade to a paid subscription. Visit our FAQ for more information.

We recently started mirroring our images from ghcr.io to docker.io, and we rely on this free team organizations. The impact is minimal for LibreTime, as we never relied on docker hub for hosting our images, the docker-compose file always referenced the images on ghcr.io.

But since we have some images hosted at docker hub, here is what I propose to get us out of this situation:

• We apply for the docker hub open source program https://www.docker.com/community/open-source/application/. We renew this application every year.
• We prefer ghcr.io as base registry for all our images. We use the docker.io registry only for the discoverability it brings to the project until we find a better alternative and that moving away from there brings some benefits.
• We assume Docker hub might do similar moves in the future: we must not depend on docker hub and be prepared to drop it at any time.

@paddatrapper I need your green light to apply for the open source program on docker hub.

We need access to the discourse administration.

@Robbt is currently the admin, but we should probably add some more admins.

I mainly need this to setup a template for users that ask for help, they need to fill more information.

I will start to get angry at those who don't, but in the the end is our fault because we don't provide information about what information to collect, hence the template I want to setup.

We are planning on moving the community channels (currently on a Mattermost server, hosted by @paddatrapper) to a Matrix Space.

An alternative would be to continue hosting a Mattermost server, but on our own infrastructure.

• The initial proposal came from @paddatrapper
• I am in favor of moving to Matrix.

This will need the following steps :

• Set up the matrix space
• Create a blog post to announce the change. The blog post will also be sent on the current Mattermost and the Forum.
• Archive the data from Mattermost (channels, not the private message). This data should not be publicly accessible for unknown users or robots, as it was previously hidden behind a registration wall.
• Shutdown the Mattermost server

I am unsure about the timeline, once agreed, I think the move can be pretty quick. Maybe we need to keep the deprecated Mattermost server one week up after the announcement (tough, I don't see any reason why) ?

Before doing so, we need some more input from the maintainers of the project. @libretime/administrators