Live data from Hacker News

Dstat project ended due to RedHat replacing it with its own dstat tool

github.com

21–30 of 159 posts

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#21
post #9

Earlier quoted context omitted.

> I wish they had changed the name if they were forking or reimplementing without permission. Has the name not changed to "pcp", or am I missing something? "pcp dstat" appears to be a command, but that seems like a reasonable abbreviation for "hey pcp, please give me a dstat-like interface". [Edit] Correction. https://github.com/dagwieers/dstat/issues/156 says the following, so there is a compatibility symlink using…

> community developers requesting access to help were being ignored This is not true, I have not been contacted. I learned from Fedora's decision to replace Dstat with PCP months after it was already decided. So it's not like I have had a choice. The choices I have today are: 1. Continue with a project, while Fedora/RHEL is shipping a tool by the same name (with 90% of my code) 2. Rename the original Dstat project, w…

GitHub PRs being ignored seems totally true.

https://github.com/dagwieers/dstat/pulls?q=is%3Apr+is%3Aclos...

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#23
post #16
post #6

Earlier quoted context omitted.

The git repo linked here has 6 commits on Jan 16, 2019. And Nov 23, 2016 the last new commits before then.

To contrast, Redhat's pcp dstat looks like it was mostly developed during 2018 (a period during which dstat had been totally inactive for 2-3 years): https://github.com/performancecopilot/pcp/commits/master/src...

oh god. it's based on pcp o.O

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#24
Having read through this post and the previous comments[1] I have to say that RedHat did the right thing in the completely worst possible way.

Stealing the project name was a mistake. The authors are right to be upset by the fact that people used to get their project when they did "yum install dstat" but now are getting a completely different (and not completely compatible) project. I think a lot of the friction could have gone away if they had just named it "pcp-dstat" or something similar, but instead they essentially took this person's namespace without discussion, and really for no good reason that I can tell.

The other issue is that forking a project without even talking with the people running it is a very touchy subject. Ultimately it does look like the project was dead- even to the point where people were asking to contribute but not getting responded to, and the fact that python2 is EOL and python3 support wasn't added until after this drama started shows that the project wasn't really "active". So while I do think they should have reached out, I totally understand why that slipped their mind.

So at this point I think RedHat should apologize and fix the package name.

[1] https://github.com/dagwieers/dstat/issues/156

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#25
post #21

Earlier quoted context omitted.

> community developers requesting access to help were being ignored This is not true, I have not been contacted. I learned from Fedora's decision to replace Dstat with PCP months after it was already decided. So it's not like I have had a choice. The choices I have today are: 1. Continue with a project, while Fedora/RHEL is shipping a tool by the same name (with 90% of my code) 2. Rename the original Dstat project, w…

GitHub PRs being ignored seems totally true. https://github.com/dagwieers/dstat/pulls?q=is%3Apr+is%3Aclos...

Sure, and Red Hat being paid for RHEL shipping Dstat for a decade could have helped out. But instead they decided to replace it.

And as a result I don't see a point continuing a project with the same name.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#27
post #21

Earlier quoted context omitted.

> community developers requesting access to help were being ignored This is not true, I have not been contacted. I learned from Fedora's decision to replace Dstat with PCP months after it was already decided. So it's not like I have had a choice. The choices I have today are: 1. Continue with a project, while Fedora/RHEL is shipping a tool by the same name (with 90% of my code) 2. Rename the original Dstat project, w…

GitHub PRs being ignored seems totally true. https://github.com/dagwieers/dstat/pulls?q=is%3Apr+is%3Aclos...

Which PRs are you talking about? PRs I see there are either all from the last 4 hours or from 2016 and earlier that were merged.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#28
post #14
post #11

Earlier quoted context omitted.

From the git changelog, it doesn't appear to be completely unmaintained, but not very vital either: https://github.com/dagwieers/dstat/commits/master Red Hat's announcement (posted in February 2019), also cites lack of Python 3 support as another reason for replacing the original dstat, but Python 3 compatibility was added last January.

The package was removed in Fedora 29, released October 2018.

Yes, and the plan to do this was conceived before June 2018.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#29
this strongly reminds me of the hn post from five days back in which the main thread talked at some length about a very similar scenario

> "He missed a big one: you have no way to stop Linux distributions from hacking up your software, and you'll suffer the consequences of whatever they do."

https://news.ycombinator.com/item?id=19935648

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#30
post #11
post #4

Earlier quoted context omitted.

The claim is that the original is no longer being maintained. Is that true? It changes a lot about what I would think of this move.

From the git changelog, it doesn't appear to be completely unmaintained, but not very vital either: https://github.com/dagwieers/dstat/commits/master Red Hat's announcement (posted in February 2019), also cites lack of Python 3 support as another reason for replacing the original dstat, but Python 3 compatibility was added last January.

Yeah, I added python 3 support after I learned that was the main reason for replacing it. It took me less than an hour to make it work on Python 3, including all (but 2) of the plugins.

And given that PCP is using most of the original code, they must have made the same changes to get Python 3 support.

Post reply on HN