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.

[real-or-random]

@dengste Two users here have suggested they'd be willing to help. That's awesome! Can you invite (one of) them as collaborators? That's a very quick thing to do, and that would be awesome and would unblock a lot of PRs here.

[Titan-C]

The entire point of free software is that anyone can continue their fork. You don't need to ask for maintainer permission, simply fork your way. Maintainer job is a hard and poorly rewarded job. Life moves on, for many of us and we can't keep maintaining some projects. It is enough to have a well documented issue advertising your fork. And if it adds enough value people will move to it. Today I don't even find elpa/melpa even relevant, you can pin repositories directly from github and to specific commits, so any fork will do to the end user it only needs a little bit more work on their side, but they can update anytime they want.

Final note, I once used this project, I tried to PR on it but it didn't move forward. Then I went full on my fork, it is currently even another take. It does not sync it only pushes entries individually. It is a general downgrade on features, but it solves my problem better and today for me it is also feature complete. It does not need a maintainer.

So please embrace free software and do your thing. If it is broken fix and share. If you want it other way, change it and share. No need to ask for permission.

[real-or-random]

The entire point of free software is that anyone can continue their fork. You don't need to ask for maintainer permission, simply fork your way.

Sure! But projects usually flourish if multiple people (developers and users) can agree on a single fork, and join their efforts. I'm merely trying to nudge @dengste. If that won't work, then the natural next step is to move to a fork. Maybe @jackkamm 's fork could be good candidate.

Maintainer job is a hard and poorly rewarded job. Life moves on, for many of us and we can't keep maintaining some projects.

No doubt!

[hny-gd]

How about collectively "deciding" @jackkamm 's is the active one by replying to bugs/pull requests here that they should be opened on @jackkamm 's repo instead, assuming that @jackkamm is agreeing with that of course? I really would hate it if all the PR's and bug reports etc are in vain and also the work that is done on the fork is invisible?

[dengste]

Sorry for being absent. I invited @jackkamm to be a collaborator for this repo. Thanks for helping!

[jackkamm]

Thanks!

I've merged in some some bugfixes now, and will merge in the VTODO sync feature soon. Note, I probably won't merge my personal branch wholesale, as it contains some experimental features not ready for master -- but I might push it as a "develop" branch later.