forever gone?

[harlentan]

I am very appreciate the forever node library. The forever is one of the greatest nodejs library.

But as the commits and pull requests show, there are not commits and mergings for 2 years.

Does this library is still under maintaining by someone?

Does the forever gone forever?

@indexzero

[enginkartal]

+1

[jkumar-roambee]

+1

[yusunglee2074]

+1

[kibertoad]

@harlentan Are there any reasons to use forever instead of pm2 these days?

[harlentan]

@harlentan Are there any reasons to use forever instead of pm2 these days?

There is a big difference between forever and pm2 , if you have used these two great tools.

The forever is friendly to use in face of small embedded daemonize process in project, which is light weight.

But pm2 is focus on making a daemon project with other abundant lifecycle management design.

[indexzero]

If you are interested in becoming a maintainer please add a ❤️reaction to this comment. Time commitment is non-trivial:

• 10 hours per month
• Regular meetings
• Tedious issue triage

But hey, that's open source! Hopefully some folks out there are ready to make a sincere commitment to forever. Personally I've been letting it be "done" – that is: fits 85%+ of use cases, continues to work.

Yes there are some edge case / corner case bugs. That's inevitable for any software with a large number of features.

Yes there are feature requests. That's inevitable for any software with a large number of users.

But! It still works on latest node for it's core use case:

$ node -v
v10.3.0
$ npm i -g forever
$ git clone git@github.com:foreverjs/forever
$ cd forever
$ forever start ./test/fixtures/server.js
warn:    --minUptime not set. Defaulting to: 1000ms
warn:    --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
info:    Forever processing file: test/fixtures/server.js
$ forever list
info:    Forever processes running
data:        uid  command             script                  forever pid   id logfile                          uptime      
data:    [0] tQJW /usr/local/bin/node test/fixtures/server.js 36589   36600    ~/.forever/tQJW.log 0:0:0:2.378 
$ curl localhost:8080
{"_":[],"$0":"/usr/local/bin/node ./test/fixtures/server.js"}

Been considering rewriting it in Rust as a way to better learn Rust – would also enable shipping a single forever binary with zero dependencies which has a ton of utility for the devops/sysadmin space it lives in.

So ... hope to hear from some of you. I cannot stress enough the time commitment. Please be sure you can make the project a priority.

[kibertoad]

@indexzero I might be interested in maintaining it (you can take a look at knex.js project if you want to check my credibility :)). I am somewhat concerned about time and meetings part, though. Could you elaborate more on how meetings are handled, how long and at what time they happen? (since I'm in Europe, might be difficult to be in sync with people from USA or Asia). Also is there some specific triage process that needs to be followed beyond typical attempts to reproduce?

[indexzero]

@kibertoad thanks for saying hi! Added you to the @foreverjs/core team as a way to continue the discussion. In general I am liberal with Github write access and cautious with npm publish access. This enables new contributors quickly, but avoids bad actors from publishing malicious code quickly.

I gave a longer talk on Keeping Important Code Alive back in 2015 if you're interested in more of my philosophy on OSS maintenance.

Meetings are generally an hour every other week. In the past similar projects of this size (e.g. winston) end up with 2-3 core contributors so scheduling is pretty easy. I am in Eastern Time so Europe is no problem.

On the issue triage topic, what is most useful is:

1. Identifying & closing duplicate issues: many issues are often straight duplicates of one another. It's important to read skim many issues before deep diving on a single one.
2. Closing issues that are not issues: frequently folks will open issues that should really be questions on StackOverflow (or a similar forum). These issues need to be closed; the reporter should politely be told to ask the question in another forum since it is not a bug.
3. Finding related "threads" / "themes" across multiple PRs & issues: there may be a feature area or feature area(s) that have a number of related issues (e.g. "Windows support", "CLI argument parsing", etc). In these cases it is useful to create new issue labels when appropriate so those feature area(s) can be looked at holistically by maintainers.

The first step is always issue triage. I have not looked at issues or PRs in quite some time so any help you can lend there would be immensely appreciated <3

[kibertoad]

@indexzero Thank you for clarification! That seems reasonable. How are meetings scheduled? When is the next one? There's quite a bit to discuss :)

[harlentan]

@kibertoad thanks for saying hi! Added you to the @foreverjs/core team as a way to continue the discussion. In general I am liberal with Github write access and cautious with npm publish access. This enables new contributors quickly, but avoids bad actors from publishing malicious code quickly.

I gave a longer talk on Keeping Important Code Alive back in 2015 if you're interested in more of my philosophy on OSS maintenance.

Meetings are generally an hour every other week. In the past similar projects of this size (e.g. winston) end up with 2-3 core contributors so scheduling is pretty easy. I am in Eastern Time so Europe is no problem.

On the issue triage topic, what is most useful is:

1. Identifying & closing duplicate issues: many issues are often straight duplicates of one another. It's important to read skim many issues before deep diving on a single one.
2. Closing issues that are not issues: frequently folks will open issues that should really be questions on StackOverflow (or a similar forum). These issues need to be closed; the reporter should politely be told to ask the question in another forum since it is not a bug.
3. Finding related "threads" / "themes" across multiple PRs & issues: there may be a feature area or feature area(s) that have a number of related issues (e.g. "Windows support", "CLI argument parsing", etc). In these cases it is useful to create new issue labels when appropriate so those feature area(s) can be looked at holistically by maintainers.

The first step is always issue triage. I have not looked at issues or PRs in quite some time so any help you can lend there would be immensely appreciated <3

Great! Thank all of you so much!