Looking for a new maintainer about shepherd HOT 25 CLOSED

@martadinata666 @moschlar If you want, we can add it to the containrrr organization with you as the maintainers, since this aligns well with the goals of the "organization" (maintaining abandoned containerization tools).
None of of me and @simskij have much time to spare to maintain another project, but perhaps a relatively well known namespace and community may be beneficial?

from shepherd.

@piksel Thanks for your offer! Personally, I would like that. But we're still waiting on a directional response from @djmaze (ping) 😉

from shepherd.

Hello @djmaze, it may be a nice idea to propose containerrr/watchtower team to fuse both projects ? @simskij @piksel
Also, in the name of open-source community, thanks for all the work you all three did and do ! 🚀

from shepherd.

Sorry for the late response. Sounds sensible to move this project to the containrrr organization as this is project so closely related to watchtower.

Also, I appreciate the offers for helping / taking over maintainership. It would feel best to me to hand over maintenance to people who already demonstrated their abilities by contributing code. So @moschlar looks like a good fit in this respect.

I currently think it would be best to move to the new organization and make 1 or 2 more people contributors, but leave me in for now as a contributor so I can have some oversight (and maybe give some "senior" advice), at least in the beginning.

So my preference would be to move to containrrr/shepherd and make @moschlar and me contributors at first. @martadinata666 would be cool if you could demonstrate your expertise by contributing a PR or reviewing one as it comes up. We could then lift this to the shoulders of multiple people :)

Doing this kind of thing for the first time so if people have (best practice) ideas to handle this process, feel free to comment!

from shepherd.

Now it's just the issue of how to create a logotype that reflects all the mixed metaphors of a shepherd for a swarm of containers 😁

from shepherd.

Now it's just the issue of how to create a logotype that reflects all the mixed metaphors of a shepherd for a swarm of containers grin

I can give it a go. I imagine a cluster of flying cargo containers with wings, shepherded by a... whale with wings? 😂 Or something.

from shepherd.

Or just something like https://github.com/google/go-containerregistry/blob/main/cmd/crane/README.md with a shepherd instead of the stork. grin

I know it makes me a bit of an a-hole, but as hinted by the name of the repo, it's a crane not a stork 😂 Suggestion is good though! I'll see what I can do.

from shepherd.

Completely different approach. Shepherd is a shell script, watchtower is written in Go.

from shepherd.

Yes, I intentionally did not start off from watchtower when starting shepherd because I realized it could be implemented with much less complexity. I do not think there is much benefit with fusing the two projects.

With that said, if someone wants to implement swarm support as a new feature of watchtower, just go ahead.

Ah, and thanks for the thanks ;)

from shepherd.

What @tigerblue77 said; a lot of respect and thanks for your work @djmaze.

Personally, I don't have any interest in swarm, nor any bandwidth to also take on maintaining shepherd. Good luck with your future projects! 🎉

from shepherd.

Hey @djmaze - since we are still using Docker Swarm and shepherd for some time (I think, at least), I can see myself helping with project maintainership (but would really rather not do that all alone, so if someone else wants to help, too, please comment)!

Do you already have thoughts on the technical details of passing on ownership? Would you prefer to keep the repository? Or should we create a GitHub organization etc. for the project?

from shepherd.

Hey @djmaze - since we are still using Docker Swarm and shepherd for some time (I think, at least), I can see myself helping with project maintainership (but would really rather not do that all alone, so if someone else wants to help, too, please comment)!

Do you already have thoughts on the technical details of passing on ownership? Would you prefer to keep the repository? Or should we create a GitHub organization etc. for the project?

Watching this after three weeks, I will step up, as I used it frequently in my homelab setup. 👍🏼

from shepherd.

Really looking forward to hearing what approach you have moved on to. Have you moved on from swarm to k8's? Or still a swarm based infra? Or something else? I guess I'll just have to be patient and wait for the blog unless you can share any more details! :-)

@dazinator No, I am still using (and loving) Docker swarm as I think Kubernetes is much too complicated for most use cases. I believe k8s only makes sense for medium to large enterprise who can afford to set up big clusters with dedicated devops teams and who need fined-grained permissions / policies etc. For my private and small business use cases, swarm makes so much more sense because it keeps complexity to a minimum.

Instead of using shepherd, my new approach is using real infrastructure-as-code. The swarm stack yamls are checked into their own git repositories – one repository per swarm cluster. And I try to always reference specific image versions. Most images nowadays use semantic versioning. I use Renovate on those repositories which will automatically create PRs for image updates. I can then merge the updates and deploy the stacks with the new versions. This feels like a much cleaner and safer approach to me. (In any case, I strongly advise not to use the latest tag for any services. That's a recipe for breakage.)

(I also use a selfmade tool for improving the swarm deployment workflow. Unfortunately there is no real documentation yet.)

from shepherd.

Or just something like https://github.com/google/go-containerregistry/blob/main/cmd/crane/README.md with a shepherd instead of the stork. 😁

from shepherd.

@piksel Really sorry for letting this sit for so long. The invitation is now expired, can you send a new one? I follow up ASAP then.

from shepherd.

It is done! 🎊

from shepherd.

Personally, I haven't been using shepherd for a long time now. (I am pursueing a different, infrastructure-as-code based approach which I might blog about in the near future.)

That's a bad precondition for maintaining a project. So if there is anyone who is still actively using it (and preferably already demonstrated their ability to contribute to this project), please step up and show your interest here.

Really looking forward to hearing what approach you have moved on to. Have you moved on from swarm to k8's? Or still a swarm based infra? Or something else? I guess I'll just have to be patient and wait for the blog unless you can share any more details! :-)

from shepherd.

@djmaze I have invited you to the organization. You should be able to make the transfer when you are ready. @moschlar and @martadinata666 have invites as well, but I won't be able to set their roles until the repo is transferred (or you can do it of course, since you should be the admin of the repo after the transfer as well).

from shepherd.

Great agreement, thanks everyone!

from shepherd.

@djmaze You should be able to transfer using https://github.com/djmaze/shepherd/transfer and selecting the containrrr organization. Let me know if there are any problems!

from shepherd.

@moschlar and @djmaze are now the maintainers, and @martadinata666 is set to triage for now. either of the maintainers can grant higher permissions when appropriate.

from shepherd.

@piksel Thanks!

I guess ideally the "official" docker image should also be moved to the containrrr organization at dockerhub. Also, the image is currently built on my own Drone instance. I don't mind if we keep it like that, but we could also move it to CircleCI as you as containrrr organization seem to be using that instead. I am open for opinions on that.

from shepherd.

It should be possible to do directly using github actions, no? I can take a stab at creating a workflow for it.

from shepherd.

Yeah, should be possible as well. Please make sure to port not only the image build but also the shellcheck run from the drone config. Cool!

from shepherd.

Closing this at the migration has now happened.

from shepherd.