ACME-DNS Organization

[gbonnefille]

What about creating an ACME-DNS Organization on GitHub ? Two main motivations:

• share the maintenance effort (PR review and acceptance) between multiple maintainers
• create a space for related (sub)projects (like the creation of Helm Chart, for example)

Currently, this repo is quite active and mostly around the Issues (as support board) while https://github.com/fritterhoff/acme-dns/ proposes regular (security) updates or https://github.com/jdpage/dnsacmed with other updates.

[joohoi]

Oh absolutely. The organization is actually already in place, and I have been planning this move for quite a while now.

The plan was probably too ambitious though, as I’m not really happy with the architecture and some decisions in the current codebase, so I planned to do a complete rewrite to publish under the organization.

The main issue with this, and many tools and software that are part of some sort of a trust chain is the integrity promises and vetting when inviting new maintainers in.

That being said, I don’t have any doubts about the authors mentioned in this issue.

On Mon 25. Apr 2022 at 19.10, Guilhem Bonnefille @.***> wrote:

What about creating an ACME-DNS Organization on GitHub ? Two main motivations:

• share the maintenance effort (PR review and acceptance) between multiple maintainers
• create a space for related (sub)projects (like the creation of Helm Chart, for example)

Currently, this repo is quite active and mostly around the Issues (as support board) while https://github.com/fritterhoff/acme-dns/ proposes regular (security) updates or https://github.com/jdpage/dnsacmed with other updates.

— Reply to this email directly, view it on GitHub https://github.com/joohoi/acme-dns/issues/301, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABH6DJJOX4X54ALWZMSTKCLVG27XPANCNFSM5UJCEWCA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[cpu]

+1 to this idea. I think I also proposed moving https://github.com/cpu/goacmedns under the org umbrella and then fell off the face of the planet before making any progress. I would still love to turn that repo over to the org if there's interest.

[gbonnefille]

The plan was probably too ambitious though, as I’m not really happy with the architecture and some decisions in the current codebase, so I planned to do a complete rewrite to publish under the organization.

Concerning such topic, if it is currently a blocker for integration of some pull-requests, I would suggest to move the actual repository in the organization and prepare the rewrite in a new repository.

[gbonnefille]

The main issue with this, and many tools and software that are part of some sort of a trust chain is the integrity promises and vetting when inviting new maintainers in.

IMHO, the motivation of creating an organization is to find a way to better help you integrating some pull requests. In a first step, giving only a « triage » permission would already help you, starting review and initial acceptance or reject... or at least discussion.

[fritterhoff]

Since my fork is mentioned here also a comment from my side ;)

As as already mentioned my intention was not to rewrite the code or to add some new features (at least not in the direct fork) but to maintain the dependencies and avoid some outdated dependencies.

I'm currently working on a sort of a fork/clone of this project as part of my master thesis but thats for a rather special use case and coupled to a specific infrastructure.

[gbonnefille]

As as already mentioned my intention was not to rewrite the code or to add some new features (at least not in the direct fork) but to maintain the dependencies and avoid some outdated dependencies.

I would be really pleased to see the tooling from fritterhoff's repository integrated in the main repository, plus an automatic publication of Docker images. In order to deal with security, we certainly have to introduce an integration branch (develop). Any push into this branch will generate a Docker image with specific tag (:staging-XYZ, :X.Y.Z-staging, :staging). These image can then be tested in staging environments by community members or automated bots. When happy, the maintainer can decide to merge develop into master. This event will produce a new stable Docker Image.

[fritterhoff]

Building such a workflow is pretty simple. I even have to admit that the status in my repository is far not "complete" and there are several options to add more features... 😉

In general the most work is done using dependabot and some more docker actions.

[webprofusion-chrisc]

An organization sounds like a good idea - one thing I'd like to add is that for me (and possibly others) the API acme-dns implements (and the maintenance of that as a "standard") is much more important than the code. I've got an alternative implementation of acme-dns using a combination of Cloudflare workers, cloud functions (and key-value storage) and dynamically scalable (nodejs-based) DNS instances, so for me staying compatible with the API is the number one priority.

[gbonnefille]

An organization sounds like a good idea - one thing I'd like to add is that for me (and possibly others) the API acme-dns implements (and the maintenance of that as a "standard") is much more important than the code. I've got an alternative implementation of acme-dns using a combination of Cloudflare workers, cloud functions (and key-value storage) and dynamically scalable (nodejs-based) DNS instances, so for me staying compatible with the API is the number one priority.

Thus, a project like acme-dns-spec with only the documentation of the API would make sense for you?

[webprofusion-chrisc]

Yes, API definition and expected/specified behaviors.

[linuxgemini]

+1 to this idea, I also (sorta) maintain my own fork at https://github.com/linuxgemini/acme-dns for more arch support and honestly keeping this great project alive is a must IMHO.

[joohoi]

So to reiterate; I'm all up for this, the organization is in place and the acme-dns repository with the current master branch is mirrored there.

I would like to have a team of 2-3 additional, trusted maintainers agreeing on shared development principles and utilizing the GitHub access controls to allow smooth continuity of the project. By access controls I mean agreeing on a workflow that includes 1-2 mandatory code reviews from other maintainers before merging etc.

Now the question is; who are up for the task? Who should I continue these discussions with?

[fritterhoff]

Hey! In general I would like to support this great project and support you maintaining the source code and the issues. Would you like to discuss it face to face/via email or here? ;)

[fritterhoff]

Maybe it would make sense to transfer this repo to the new organization so existing PRs, issues and stars get transfered?

[joohoi]

Hey! In general I would like to support this great project and support you maintaining the source code and the issues. Would you like to discuss it face to face/via email or here? ;)

I'd prefer having a f2f call to spitball ideas and thoughts properly. Also hoping to get +1 person to help with maintenance so we can call it a team ;)

Maybe it would make sense to transfer this repo to the new organization so existing PRs, issues and stars get transfered?

Absolutely, makes sense. Let's do that when we have a conclusion about how to proceed.

[fritterhoff]

I just wrote you an E-Mail :)

[bitsofinfo]

game for this as well

[cpu]

I'll be cheering from the sideline :-)

[fritterhoff]

Ping :) Did you get my e-mail?

[joohoi]

Ping :) Did you get my e-mail?

I did, but apparently dropped the ball again due to being too busy IRL, sorry.

Now during the holiday hurdles I have had to get some time off the holiday things, so I have been able to finally tackle the refactoring I have been pushing away for way too long. The current work can be seen in PR #325 and it should make the code way more maintainable while adding couple fixes and a logging feature as a side effect.

If you fellows would want to take a look into that, I'd appreciate it a lot. With the refactoring and re-visiting the codebase I think I'd be personally ready to move the organization thing forward.

Happy holidays!

[joohoi]

Oh and one thing that is huge for me in the refactoring branch is using a pure Go sqlite module, so we can get rid of CGO and do proper cross compilation down the road.

[fritterhoff]

If you fellows would want to take a look into that, I'd appreciate it a lot. With the refactoring and re-visiting the codebase I think I'd be personally ready to move the organization thing forward.

Thanks for the update. I will check the code the next few days.

[bitsofinfo]

any further thoughts on this?

[bb-Ricardo]

Hi,

was wondering if anything is happening around ACME-DNS anymore or if this is project kind of dead?

[joohoi]

We should continue on moving acme-dns to an individual organization for sure.

[joohoi]

There is the big refactoring PR to agree upon: #325

I'll have to revisit the state in the near future to complete the transfer over acme-dns/acme-dns