6 ms·

669 commits in the last year... and asking if the project is dead? I'm a bit confused here. Maybe the project is mismanaged, or there's some upstream issue wit

by casion 7y ago

669 commits in the last year... and asking if the project is dead? I'm a bit confused here. Maybe the project is mismanaged, or there's some upstream issue with package distro, but it seems to be far from dead.

petters 7y ago
It may be abandoned by everyone with release permissions.
- shakna 7y ago
  Most of the 2018 release were by techalchemy, who made commits in July. Right now, it seems like the issues raised in [0] are still a problem. The release pipeline has problems, and dragging through that isn't a priority. [0] https://github.com/pypa/pipenv/issues/3742 https://github.com/pypa/pipenv/issues/3742
guardian5x 7y ago
He talks about maintenance and making releases. Otherwise people will still deal with bugs in the "current" release that have been fixed in the master branch for a long time.
- casion 7y ago
  That would be mismanagement (and annoying of course), not "dead" I would think?
  - nwsm 7y ago
    There is no difference for the average user. I'm not going to use the code in master, I will use a package from pip, pipenv or otherwise.
    - setr 7y ago
      And even if you did, there's no guarantee that the work in master is actually in a sane state. Some try to follow models like master is always runnable, or tested/built by ci/cd, but it's often simply not the case. I've worked on atleast a few open source projects where I'd pull and build master, trying to obtain a particular bugfix, and it would fail, and I'd have to randomly rollback commits until I found a working build. In one case the project had a seperate repo for a library that wasn't kept entirely in sync with the parent project.. had to randomly move back both repos until I found a matching pair that built and ran successfully, but after the bugfix was implemented. Releases are important for anyone who isn't working on the repository directly -- they gaurantee the project is in a sane state.
      - namibj 7y ago
        There is git-bisect for that task, fyi. If you can quickly script the build and test process, it's an easy way to not be bothered manually.
thibaut_barrere 7y ago
Indeed! It doesn't seem dead at all. While having a new release could be nice, I must also say I didn't face much trouble with the last release (I do Ansible work & use pipenv+pyenv to freeze the dependencies). I'm grateful to pipenv in how it has helped me here.
levosmetalo 7y ago
Those 669 commits without a single release are pretty useless to the normal users. What would be the difference between 0 commits without a release and 669 commits without a release?
- rejschaap 7y ago
  The 0 commit project is dead or finished. The 669 commit project is clearly not finished, but also not really dead, yet.
- manigandham 7y ago
  Well for one thing it means the project isn't dead, whether or not the release is ready.
zubspace 7y ago
Determining if a project is alive or dead really is a problem. And this problem will grow from year to year. There are so many small and medium sized projects on Github, where you have no idea if they are maintained or not. Sometimes there are projects which are alive and kicking with multiple pull requests, maintainers promising changes or a major release and suddenly nothing. Sometimes smaller projects see no changes for months, but they simply work and don't need maintenance at all. Maybe the community moved elsewhere and and the project will only see bugfixes coming in and no more features? The burden of figuring this all out lies with the visitor and is a annoying hassle. I would love if Github could somehow show me on the landing page, if the project is worth investing time in. Maybe they could send a heartbeat to the maintainer and simply show the project as dead as soon as there is no response?
- _jal 7y ago
  > Maybe they could send a heartbeat to the maintainer and simply show the project as dead as soon as there is no response? If I could not automate response to that, I'd ignore it. My employer gets to make bullshit intrusions on my time like that, no way will I waste my life on make-work from Github.
  - mcv 7y ago
    Just fishing for a response wouldn't be very meaningful anyway. A far better metric would be the time it takes for a maintainer to respond to pull requests and other issues.
  - zubspace 7y ago
    > My employer gets to make bullshit intrusions on my time like that, no way will I waste my life on make-work from Github. You are not willing to give Github the information, if a project ,which you uploaded, is still active? But, will you give that information to users asking for details? Which way is more annoying to you and the users? What I want to say is, that Github will turn into a huge graveyard in the years to come, with projects long forgotten still having a landing page like it's the best thing ever. Do you want every visitor to first contact the maintainer if the thing is still alive? Isn't that a huge waste of time? In my opinion, Github will have to clean up the mess left behind by unmaintained projects at some point. The sooner they start, the easier it will be.
JulianMorrison 7y ago
From the post itself, the symptom is: people are committing, but releases are not being made.
- BlueTemplar 7y ago
  Remember that "releases" are a Github-specific feature, not a git one.
  - JulianMorrison 7y ago
    I mean releases as in, a point in time snapshot of the code that has been declared fit to use, and released for distribution to the public. Regardless of the software used to prepare this. As distinct from just pulling the latest master branch and praying it's stable.
roelschroeven 7y ago
Take SpeedCrunch for example: the current release (0.12) dates from 2015 AFAICS, and works very well for the most part. There's a bug in that release though: it thinks 0^1 is NaN. That bug was fixed in or before 2018 (https://bitbucket.org/heldercorreia/speedcrunch/issues/836/0-1-gives-nan-message https://bitbucket.org/heldercorreia/speedcrunch/issues/836/0...), but there has not been a release since. There have been a number of commits this year, but not a lot. Is the project dead or not? I honestly couldn't tell.
- Barrin92 7y ago
  not sure about the project but in a case like that the project management appears to be dead for sure, because releases should not trail vital bug fixes like that. Same for pipenv.
peterwwillis 7y ago
Similarly, Slackware Linux's last stable release was 14.2, in June, 2016, but their -current release tree was last updated.... yesterday. Now, I could be super huffy that they haven't released in years, but this is open source software that I'm not paying for. Moreover, I have the power to choose multiple alternatives. I can run the -current release. I can make my own "pseudo-release" by just forking here and calling this "14.2.1". Or I can use a different distro. It would be really entitled of me to demand Patrick make a new release just because I want one, especially when he doesn't owe me anything, and I have multiple alternatives. And besides, the project is still going, it's just not doing what I want it to do; and that's Pat's prerogative.
- chipotle_coyote 7y ago
  I mean, you're right on all points, yet I confess I would be a lot more willing to give Slackware a try again if it would return to having a more-or-less annual official release, like it managed from its start in 1993 up through 2013. (Mast years prior to 2000 it had more than one release a year!) There are things I (dimly) remember genuinely liking about Slackware in terms of its philosophy, but as near as I can tell the official installation method is "install the most recent ISO, then update from there," and when the most recent ISO is three and a half years old, that's not a great look. We've now gone the longest length in Slackware's history without even a point release. I wouldn't demand Patrick make a new release, but I don't think it's wildly unreasonable to expect one by now. Bringing it back to the original article, I think the same can be said of pipenv.
- BlueTemplar 7y ago
  Are those Github "releases" or git tags? Or are they using a specific branch for that?
kstrauser 7y ago
It's definitely tapered off, though: https://github.com/pypa/pipenv/graphs/commit-activity https://github.com/pypa/pipenv/graphs/commit-activity There's no activity in December. There was one commit in November, and that removed a Fedora version number from the readme.
zanny 7y ago
Clementine the music player is my go-to example of this phenomenon. Its got 750 commits in since its last release in 2016, there is regular merging, but the project management is in a place where trying to deploy builds to every platform is acting as a barrier to any new releases. It recently finally merged its Qt5 support into master (which was in a working state since 2014) about two months ago. That might help the release process. What doesn't help is that a consumer facing product of that scale is a nightmare to manage - it has over 2k open issues on Github but probably 95% of them are "I don't know how to do X" tech support kinds of things.

by casion 7y ago

petters 7y ago

It may be abandoned by everyone with release permissions.

shakna 7y ago
Most of the 2018 release were by techalchemy, who made commits in July. Right now, it seems like the issues raised in [0] are still a problem. The release pipeline has problems, and dragging through that isn't a priority. [0] https://github.com/pypa/pipenv/issues/3742 https://github.com/pypa/pipenv/issues/3742

guardian5x 7y ago

He talks about maintenance and making releases. Otherwise people will still deal with bugs in the "current" release that have been fixed in the master branch for a long time.

casion 7y ago
That would be mismanagement (and annoying of course), not "dead" I would think?
- nwsm 7y ago
  There is no difference for the average user. I'm not going to use the code in master, I will use a package from pip, pipenv or otherwise.
  - setr 7y ago
    And even if you did, there's no guarantee that the work in master is actually in a sane state. Some try to follow models like master is always runnable, or tested/built by ci/cd, but it's often simply not the case. I've worked on atleast a few open source projects where I'd pull and build master, trying to obtain a particular bugfix, and it would fail, and I'd have to randomly rollback commits until I found a working build. In one case the project had a seperate repo for a library that wasn't kept entirely in sync with the parent project.. had to randomly move back both repos until I found a matching pair that built and ran successfully, but after the bugfix was implemented. Releases are important for anyone who isn't working on the repository directly -- they gaurantee the project is in a sane state.
    - namibj 7y ago
      There is git-bisect for that task, fyi. If you can quickly script the build and test process, it's an easy way to not be bothered manually.

thibaut_barrere 7y ago

Indeed! It doesn't seem dead at all. While having a new release could be nice, I must also say I didn't face much trouble with the last release (I do Ansible work & use pipenv+pyenv to freeze the dependencies). I'm grateful to pipenv in how it has helped me here.

levosmetalo 7y ago

Those 669 commits without a single release are pretty useless to the normal users. What would be the difference between 0 commits without a release and 669 commits without a release?

rejschaap 7y ago
The 0 commit project is dead or finished. The 669 commit project is clearly not finished, but also not really dead, yet.
manigandham 7y ago
Well for one thing it means the project isn't dead, whether or not the release is ready.

zubspace 7y ago

Determining if a project is alive or dead really is a problem. And this problem will grow from year to year. There are so many small and medium sized projects on Github, where you have no idea if they are maintained or not. Sometimes there are projects which are alive and kicking with multiple pull requests, maintainers promising changes or a major release and suddenly nothing. Sometimes smaller projects see no changes for months, but they simply work and don't need maintenance at all. Maybe the community moved elsewhere and and the project will only see bugfixes coming in and no more features? The burden of figuring this all out lies with the visitor and is a annoying hassle. I would love if Github could somehow show me on the landing page, if the project is worth investing time in. Maybe they could send a heartbeat to the maintainer and simply show the project as dead as soon as there is no response?

_jal 7y ago
> Maybe they could send a heartbeat to the maintainer and simply show the project as dead as soon as there is no response? If I could not automate response to that, I'd ignore it. My employer gets to make bullshit intrusions on my time like that, no way will I waste my life on make-work from Github.
- mcv 7y ago
  Just fishing for a response wouldn't be very meaningful anyway. A far better metric would be the time it takes for a maintainer to respond to pull requests and other issues.
- zubspace 7y ago
  > My employer gets to make bullshit intrusions on my time like that, no way will I waste my life on make-work from Github. You are not willing to give Github the information, if a project ,which you uploaded, is still active? But, will you give that information to users asking for details? Which way is more annoying to you and the users? What I want to say is, that Github will turn into a huge graveyard in the years to come, with projects long forgotten still having a landing page like it's the best thing ever. Do you want every visitor to first contact the maintainer if the thing is still alive? Isn't that a huge waste of time? In my opinion, Github will have to clean up the mess left behind by unmaintained projects at some point. The sooner they start, the easier it will be.

JulianMorrison 7y ago

From the post itself, the symptom is: people are committing, but releases are not being made.

BlueTemplar 7y ago
Remember that "releases" are a Github-specific feature, not a git one.
- JulianMorrison 7y ago
  I mean releases as in, a point in time snapshot of the code that has been declared fit to use, and released for distribution to the public. Regardless of the software used to prepare this. As distinct from just pulling the latest master branch and praying it's stable.

roelschroeven 7y ago

Take SpeedCrunch for example: the current release (0.12) dates from 2015 AFAICS, and works very well for the most part. There's a bug in that release though: it thinks 0^1 is NaN. That bug was fixed in or before 2018 (https://bitbucket.org/heldercorreia/speedcrunch/issues/836/0-1-gives-nan-message https://bitbucket.org/heldercorreia/speedcrunch/issues/836/0...), but there has not been a release since. There have been a number of commits this year, but not a lot. Is the project dead or not? I honestly couldn't tell.

Barrin92 7y ago
not sure about the project but in a case like that the project management appears to be dead for sure, because releases should not trail vital bug fixes like that. Same for pipenv.

peterwwillis 7y ago

Similarly, Slackware Linux's last stable release was 14.2, in June, 2016, but their -current release tree was last updated.... yesterday. Now, I could be super huffy that they haven't released in years, but this is open source software that I'm not paying for. Moreover, I have the power to choose multiple alternatives. I can run the -current release. I can make my own "pseudo-release" by just forking here and calling this "14.2.1". Or I can use a different distro. It would be really entitled of me to demand Patrick make a new release just because I want one, especially when he doesn't owe me anything, and I have multiple alternatives. And besides, the project is still going, it's just not doing what I want it to do; and that's Pat's prerogative.

chipotle_coyote 7y ago
I mean, you're right on all points, yet I confess I would be a lot more willing to give Slackware a try again if it would return to having a more-or-less annual official release, like it managed from its start in 1993 up through 2013. (Mast years prior to 2000 it had more than one release a year!) There are things I (dimly) remember genuinely liking about Slackware in terms of its philosophy, but as near as I can tell the official installation method is "install the most recent ISO, then update from there," and when the most recent ISO is three and a half years old, that's not a great look. We've now gone the longest length in Slackware's history without even a point release. I wouldn't demand Patrick make a new release, but I don't think it's wildly unreasonable to expect one by now. Bringing it back to the original article, I think the same can be said of pipenv.
BlueTemplar 7y ago
Are those Github "releases" or git tags? Or are they using a specific branch for that?

kstrauser 7y ago

It's definitely tapered off, though: https://github.com/pypa/pipenv/graphs/commit-activity https://github.com/pypa/pipenv/graphs/commit-activity There's no activity in December. There was one commit in November, and that removed a Fedora version number from the readme.

zanny 7y ago

Clementine the music player is my go-to example of this phenomenon. Its got 750 commits in since its last release in 2016, there is regular merging, but the project management is in a place where trying to deploy builds to every platform is acting as a barrier to any new releases. It recently finally merged its Qt5 support into master (which was in a working state since 2014) about two months ago. That might help the release process. What doesn't help is that a consumer facing product of that scale is a nightmare to manage - it has over 2k open issues on Github but probably 95% of them are "I don't know how to do X" tech support kinds of things.