Suggestion: Fork into org-caldav2 to continue development

[hny-gd]

Dear org-caldav community,

to continue a side-track started in #233 about ensuring org-caldav does not remain unmaintained, I would like to make the suggestions below.

I know quite well that I am mainly talking about other people's lives, projects and time here which of course is none of my business, so please just see this as me trying to start a discussion.

From looking at most org-caldav repositories:

• We could use @whirm 's org-caldav branch as the new master for org-caldav2 since it incorporates @grauschnabel 's work which is (afaict) the code-size-wise biggest change
• It would need to be rebased to include the latest @dengste work
• After rebasing it, the currently opened pull requests by @hubearth + @adrianparvino and potentially the older & doc related PRs could be sent to the new project
• Maybe all the major current contributors who would be open to this idea could be added directly with write permission to the new branch so the way forward (reviewing future PRs etc) is resting on more shoulders right from the beginning

Alternatively, I could fork the latest @dengste version into a new org-caldav2 tree myself as well and like above add whoever would agree to this approach (e.g. @whirm, @grauschnabel) to the new fork from my side but again I would need your guys help to merge the latest stuff.

Like I wrote in the other thread, I am no elisp buff (yet) but I would be happy to try to help where I can to get this back on track (e.g. trying to get a new org-caldav2 into MELPA etc).

From there, it also might be an idea to look at @girzel 's suggestion to maybe move towards core url-dav.el

Please let me know your thoughts.

[grauschnabel]

Your idea is good but I cannot see the point calling it org-caldav2 because the number would make me expect that this is a alternativ way of doing the same thing. So I would suggest to just do the work on any fork, and at the same time talk to dengste if there is a way to make your fork the main fork that pushes the work to elpa (or so). This would be the right way from my point of view.

[grauschnabel]

If we don't get in touch with @dengste anymore (no commits in a year) maybe we can talk to the melpa group about a was to take over org-caldav. Is it possible to make it a workgroup on github like it's possible on gitlab? Maybe we should have more than one maintainer,if org-caldav gets so many users?

[grauschnabel]

If we cannot reach @dengste , maybe we just need to send a PR on https://github.com/melpa/melpa/blob/master/recipes/org-caldav to load the sources from another repository. But lets do the work first, we need to be clear that its working correctly.

[girzel]

I hope @dengste isn't actually awol, and is merely very, very sick of this code :). It would be far preferable simply to add some more contributors to this repo.

[dengste]

Hi everybody,

I'm still here, but I simply didn't have the mental space do deal with side projects these past 12 months or so, not just because of the pandemic and all that goes with it, but I also switched jobs. But here in Germany schools and nurseries are now fully open again and I'm slowly settling into my new job, so things are getting better. If nothing goes wrong, I will look at the open merge requests next weekend.

[hny-gd]

That is so great to hear, @dengste!

Not only regarding the project but also simply because you are doing well. 😀

I will therefore close this issue.

[dengste]

Hey all,

as you can see I couldn't make it because unfortunately some family issues kept me occupied. I'm sorry and I can only ask for some more patience with me.

Thanks, David

[hny-gd]

Hi David,

I can only speak for myself, but since I have opened the issue I would like to reply: I really appreciate all the work you have done on this and also that you have made it available publicly. I am quite aware that you are doing this in your spare time and for free and now you feel obliged even though you don't owe us anything - no need to feel bad! :-)

Having said this and clearly understanding that this is your decision, maybe you want to think about adding additional maintainers to the project or about @girzel's suggestion to try having this functionality merged into core Emacs as IMHO it would be a good fit.

In any case, have a good week!

Stephan

[mooseyboots]

cd another option perhaps be to add some of the more proactive contributors (forkers, etc) to the repo as actual github contributors so that they can evaluate each other's PRs and merge?

looks like dengste still never found time to working on any PRs since before their comments above...

[hpfr]

It's been just about a year since @dengste last commented here. At this point I think anyone is welcome to create a fork for merging the open PR's or dealing with issues; it's just a matter of who is willing to maintain it. @whirm does have multiple open PR's including the VTODO PR, so he would be a good candidate, but he doesn't look particularly active either.

I guess anyone can comment here if they're comfortable with people using their fork and whether they think they can allocate any time to maintenance, and if not, people can just keep doing their own thing if they find @dengste's tree lacking.

[dengste]

Hi everyone,

again, I'm sorry I don't have time to work on this. I also see that it cannot continue like this. Instead of forking, how about I invite some of you to become maintainers (or "collaborators", as GitHub calls this), so that you can review/merge pull requests? The only condition I have is that whoever wants to do this has good knowledge of Emacs Lisp and Emacs packages in general.

[girzel]

Thanks for being willing to open the doors! I agree that adding collaborators would be far preferable to forking. Though I also seem to have less and less time for Emacs hacking, I'd love to be added on to the repo -- along with a few others, I hope!

[jackkamm]

I'd be willing to be added as a co-maintainer and help with review/merge of pull requests.