I think it would be better to foster an atmosphere of discussion which leads to a clear delineation of what will happen before someone goes and puts in the effort to implement it. Pull requests can either fix a bug or implement an intended and accepted feature; all others are closed sight unseen.
Yeah. Plays into the “old is bad” idea, where people will check github to see when the last commit happened, in order to know whether a package is worthwhile.
I tend to check github (or other version-control system) for whether there’s been a commit in, say, the past 4-5 years, as a proxy for whether software is at all maintained. Stable software doesn’t usually need major updates, so very light maintenance is fine. But my experience with software that has had literally no maintainer or releases in years has been generally bad. It usually has a mixture of bitrot, bugs dozens of people have hit but nobody has fixed (sometimes with patches in the VCS that nobody’s applied), and inability to function in a modern environment (e.g. missing or broken UTF-8 support). An example of stable but lightly maintained software is the “heirloom” version of troff/nroff: the vast majority of code and features date to the 1970s, but it’s actively maintained.
The period of time that counts as too long varies by type of software and environment of course. A web framework that hasn’t been maintained in 2 years often has more problems than a C library whose last release was 2 years ago (but I’d be wary of a C library whose maintainer disappeared 10 years ago).
I do occasionally use things that haven’t had a release in literally 25+ years (most recently, some old Lisp packages). They may have good fundamentals, but they rarely work out-of-the-box, and it’s often a good amount of work to get everything sorted out.
Maybe a better metric is to look at the task tracker. For example, one could look at the demographic of tasks in that tracker and look at things like feature vs bugs ratio. You could also look at things like how fast bug reports are commented on. I might even consider looking at closed issues to see that as long as the maintainer is closing feature requests saying they are out of scope or already implemented, then I would claim the project is actively maintained.
Yesterday djm added a fairly simple feature to doas. I have a default deny policy for doas contributions, but I said ok because nobody had added anything this release cycle. It only took about 12 hours for somebody to discover that the parsing changes made some previously valid config files invalid. The price of yes.
Yes, but there’s no test for using ‘=’ in a particular place, which used to work but now needs to be quoted. It’s a grammar like any other. If you add a keyword, anybody already using that word for a different purpose will have a bad day.
I wonder what @jcs’s opinion is on this matter regarding the lobsters repo. I’ve noticed that many issues and pull requests are tagged, but no discussion occurs, and the desired features aren’t implemented.
I think it would be better to foster an atmosphere of discussion which leads to a clear delineation of what will happen before someone goes and puts in the effort to implement it. Pull requests can either fix a bug or implement an intended and accepted feature; all others are closed sight unseen.
Many projects fail to specify their scope and are therefore susceptible to patch creep.
Yeah. Plays into the “old is bad” idea, where people will check github to see when the last commit happened, in order to know whether a package is worthwhile.
I tend to check github (or other version-control system) for whether there’s been a commit in, say, the past 4-5 years, as a proxy for whether software is at all maintained. Stable software doesn’t usually need major updates, so very light maintenance is fine. But my experience with software that has had literally no maintainer or releases in years has been generally bad. It usually has a mixture of bitrot, bugs dozens of people have hit but nobody has fixed (sometimes with patches in the VCS that nobody’s applied), and inability to function in a modern environment (e.g. missing or broken UTF-8 support). An example of stable but lightly maintained software is the “heirloom” version of troff/nroff: the vast majority of code and features date to the 1970s, but it’s actively maintained.
The period of time that counts as too long varies by type of software and environment of course. A web framework that hasn’t been maintained in 2 years often has more problems than a C library whose last release was 2 years ago (but I’d be wary of a C library whose maintainer disappeared 10 years ago).
I do occasionally use things that haven’t had a release in literally 25+ years (most recently, some old Lisp packages). They may have good fundamentals, but they rarely work out-of-the-box, and it’s often a good amount of work to get everything sorted out.
Maybe a better metric is to look at the task tracker. For example, one could look at the demographic of tasks in that tracker and look at things like feature vs bugs ratio. You could also look at things like how fast bug reports are commented on. I might even consider looking at closed issues to see that as long as the maintainer is closing feature requests saying they are out of scope or already implemented, then I would claim the project is actively maintained.
True tangential story…
Yesterday djm added a fairly simple feature to doas. I have a default deny policy for doas contributions, but I said ok because nobody had added anything this release cycle. It only took about 12 hours for somebody to discover that the parsing changes made some previously valid config files invalid. The price of yes.
Does doas have automated unit & regression tests?
Yes, but there’s no test for using ‘=’ in a particular place, which used to work but now needs to be quoted. It’s a grammar like any other. If you add a keyword, anybody already using that word for a different purpose will have a bad day.
Dammit, I was going to quote that movie but the author did right at the end :(
I wonder what @jcs’s opinion is on this matter regarding the lobsters repo. I’ve noticed that many issues and pull requests are tagged, but no discussion occurs, and the desired features aren’t implemented.