gofrs / help-requests

request help from the gofrs to maintain a project
49 stars 3 forks source link

github.com/jasonlvhit/gocron #34

Closed fgblomqvist closed 5 months ago

fgblomqvist commented 5 years ago

Where is the project currently hosted? https://github.com/jasonlvhit/gocron

What languages other than Go does the project utilize? None

When was the project's last activity? Mar 12, 2018 (the only change since then was to update the README to say that the project is looking for maintainers)

Does the project have a maintainer, or a maintainer looking for someone to take over the project? It's currently looking for maintainers, which can be seen in the README (proof).

What active projects replicate the popular functionality of this project, if any? There are a few other projects that have similar functionality, but none of them are maintained either and as far as I can see, goCron is the most feature-complete one (that also has a following, even if it's probably fading away due to the maintainance issue).

A list can be found here: https://github.com/avelino/awesome-go#job-scheduler

The only one imo worth mentioning from that llist is clockwork, just because it was also touched in 2018. However, I don't have too much insight into it (it looks the same, with probably one or two less features I'm guessing).

What are some example projects that make use of this package? According to godocs "only" a mere 41 packages imports goCron, but goCron itself is still starred by more than 1000 people and I feel like more users would use it if it was in better shape. E.g. after talking to two people through the issues page both of them run their own forks that their companies use, just because the main one has a bunch of good PRs waiting to be accepted, and other issues. Since goCron has 175 forks I'm guessing those 2 cases are not the only ones.

Are there any outstanding critical bugs that result in the library being totally unusable or insecure? Not really, it's more overall stuff here and there that makes it unsuitable for production use. However, most/all of those issues have already been fixed in PRs, they just haven't been accepted.

What else would you like to mention about the project? I think the API for it is clean, and it also replicates other well-known packages in other languages (as is stated in the readme), making it a no-brainer to use this package if you're looking for a cron-like scheduler. Furthermore, I think the project has potential for improvement. Not only bugfixing but adding a few useful features.

Finally, the two more-so production-ready forks I was linked to were these: https://github.com/marcsantiago/gocron https://github.com/marksalpeter/gocron

The first one already incorporated a bunch of the good PRs, and did some proper restructuring on top of that. The second one seems to have done something similar, though, I haven't looked into it in more detail. It might even be a better idea to base a take-over on one of those forks, to lessen the work required.

I haven't spoken to the actual repo owner (jasonlvhit) yet since I just wanted to run this by you guys before I do (as in, whether taking over the maintenance of it would be of interest). But if it is of interest, I can definitely try to do some meddling to get things started. My own interest in this project is that it's something I'm planning to use in production, but at the current state, I would most likely fork one of the other production-ready forks, and then build new features and do maintenance on one of them, which just makes the problem worse lol. Figured it was better to try to "rescue" it before I do that :)

dylan-bourque commented 5 years ago

To be honest, I don't think this particular package is terribly useful. It claims to be a "cron job scheduler", but I don't see any logic for parsing cron expressions. It also appears to only support "jobs" being defined as Go functions, which will limit the the scalability.

We're using https://github.com/robfig/cron for work projects, which has very similar functionality and includes a full cron expression parser. Even still, we are using that package only as a cron expression parser.

@fgblomqvist If you will need any sort of scalability, I would recommend you look into something like Hashicorp's Nomad, or any of the other existing cluster schedulers, rather than take a dependency on an in-memory "job scheduler".

fgblomqvist commented 5 years ago

You might be right in that robfig/cron is superior in terms of features. Though, while the name surely is a bit misleading, the purpose of goCron is to more-so mimic the features of the Ruby clockwork and Python schedule packages. As in, it is more easily readable than the standard cron notation. But yeah, one could argue that it's not needed I suppose. Anyhow, sadly, robfig/cron looks pretty poorly managed as well (a lot of open PRs that should either be merged or closed, also got some seemingly critical issues that haven't been tended to). Maybe robfig/cron could benefit from some help from gofrs?

Relying on an in-memory scheduler is indeed not ideal and not intended to be a long-term solution (more of a stepping stone). Took a look at Nomad and it looks solid, though, it would naturally take some effort to migrate to it. Definitely something I'd consider in the future. Atm we use goCron together with RabbitMQ, which does the job for now.

JohnRoesler commented 4 years ago

Hello all! @Streppel and myself have been maintaining this library over at https://github.com/go-co-op/gocron. We already have >300 stars but would like to find ways to alert as many of the >2K star-ers of the jasonlvhit version as possible. We have tried to get in contact with Jason for some time, but have had no luck and as such moved it over.

While it doesn't support cron expressions, the lightweight and intuitive nature of the package has made it useful to many for scheduling activities.

ldez commented 5 months ago

The fork ttps://github.com/go-co-op/gocron is now the replacement based on a fork.

So I closed this issue.