Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looking for a new maintainer #96

Closed
djmaze opened this issue Feb 12, 2023 · 25 comments
Closed

Looking for a new maintainer #96

djmaze opened this issue Feb 12, 2023 · 25 comments

Comments

@djmaze
Copy link
Collaborator

djmaze commented Feb 12, 2023

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.

@tigerblue77
Copy link

tigerblue77 commented Feb 21, 2023

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 ! 🚀

@volschin
Copy link

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

@djmaze
Copy link
Collaborator Author

djmaze commented Feb 26, 2023

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 ;)

@simskij
Copy link
Member

simskij commented Feb 27, 2023

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! 🎉

@moschlar
Copy link
Collaborator

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?

@dazinator
Copy link

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! :-)

@martadinata666
Copy link

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. 👍🏼

@piksel
Copy link
Member

piksel commented Apr 4, 2023

@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?

@moschlar
Copy link
Collaborator

moschlar commented Apr 4, 2023

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

@djmaze
Copy link
Collaborator Author

djmaze commented Apr 9, 2023

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!

@djmaze
Copy link
Collaborator Author

djmaze commented Apr 9, 2023

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.)

@piksel
Copy link
Member

piksel commented Apr 10, 2023

@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).

@piksel
Copy link
Member

piksel commented Apr 10, 2023

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 😁

@moschlar
Copy link
Collaborator

Great agreement, thanks everyone!

@simskij
Copy link
Member

simskij commented Apr 11, 2023

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.

@moschlar
Copy link
Collaborator

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

@simskij
Copy link
Member

simskij commented Apr 11, 2023

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.

@djmaze
Copy link
Collaborator Author

djmaze commented Apr 26, 2023

@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.

@piksel
Copy link
Member

piksel commented Apr 27, 2023

@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!

@djmaze
Copy link
Collaborator Author

djmaze commented Apr 27, 2023

It is done! 🎊

@piksel
Copy link
Member

piksel commented Apr 28, 2023

@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.

@djmaze
Copy link
Collaborator Author

djmaze commented Apr 28, 2023

@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.

@piksel
Copy link
Member

piksel commented Apr 28, 2023

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

@djmaze
Copy link
Collaborator Author

djmaze commented Apr 28, 2023

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!

@simskij
Copy link
Member

simskij commented Apr 28, 2023

Closing this at the migration has now happened.

@simskij simskij closed this as completed Apr 28, 2023
andrew-dixon added a commit to andrew-dixon/shepherd that referenced this issue May 31, 2023
Removing new maintainer text as issue containrrr#96 has now been completed and closed.
djmaze pushed a commit that referenced this issue Jul 24, 2023
Removing new maintainer text as issue #96 has now been completed and closed.
moschlar added a commit that referenced this issue Oct 30, 2023
[Full Changelog](0.7.0...1.8.0)

**Breaking changes:**

- The docker image registry location has been changed to the containrrr organisation:
  `containrrr/shepherd`

**Implemented enhancements:**

- armhf support [\#108](#108)
- Switch to official docker image v24 [\#107](#107) ([djmaze](https://github.com/djmaze))
- Restrict runtime of "docker service update" using "timeout" [\#98](#98) ([fooflington](https://github.com/fooflington))
- Add example for usage with swarm-cronjob [\#89](#89) ([djmaze](https://github.com/djmaze))

**Fixed bugs:**

- Can't update some services: no such manifest [\#105](#105)
- Service gets stuck when calling "docker service update" and won't progress [\#97](#97)
- fix: docker service update with `--detach=false` hangs on services wi… [\#104](#104) ([AliRezaBeitari](https://github.com/AliRezaBeitari))
- Fix defunc VERBOSE handling [\#91](#91) ([sebthom](https://github.com/sebthom))

**Closed issues:**

- How does it determine if there is an update or not? [\#111](#111)
- Looking for a new maintainer [\#96](#96)
- New OCI manifest issue [\#92](#92)
- Run service update at a fixed time [\#88](#88)
- docker swarm 20.10.12 | "docker service update" requires exactly 1 argument. [\#83](#83)
- Error updating service, does not exist or it is not available when using a duplicate registry [\#78](#78)

**Merged pull requests:**

- Add apprise type and additional error notification [\#118](#118) ([andyloree](https://github.com/andyloree))
- Rename image in docs [\#114](#114) ([moschlar](https://github.com/moschlar))
- Fix release workflow [\#113](#113) ([moschlar](https://github.com/moschlar))
- Update README.md [\#103](#103) ([andrew-dixon](https://github.com/andrew-dixon))
- ci: add basic github actions for build/release [\#101](#101) ([piksel](https://github.com/piksel))
- correct misleading description of WITH\_NO\_RESOLVE\_IMAGE [\#100](#100) ([alex-vg](https://github.com/alex-vg))
- Move example configs to their own folder [\#99](#99) ([djmaze](https://github.com/djmaze))
- Add documentation about `REGISTRIES_FILE` [\#94](#94) ([tito](https://github.com/tito))
- Minor refactoring [\#90](#90) ([sebthom](https://github.com/sebthom))

Closes: #117
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants