The decision to do this was made before June 2018, 18 months after the last activity. One of the reasons cited was lack of activity, but that is no thanks to them, I guess.
That is why I am convinced the goal was to replace it from the onset, there was no interest in helping out the project. In fact "no activity" was the right excuse to make their action seem legitimate. Attempting to contact the project could have jeopardized that plan.
They could have just removed "dstat" from the distribution, and added a note that users can now use pcp-dstat. But now they made it impossible for users to add the original dstat. Let alone the support nightmare of having a different tool with the same name. There's no winning this one.
>there was no interest in helping out the project.
They saw that people were filing issues and making pull requests and that those people were getting total radio silence. I can understand how someone might think "well, people are already trying to 'help the project' and the maintainer isn't even acknowledging it, so it's a waste of time".
And while again I totally understand and agree that they should have tried to contact you, you've known about the removal for like 9 months and you apparently never reached out to them either? Like, a couple words in reply to a bugzilla or an IRC message does not amount to picking a fight with a company.
I am sure they made a sound business decision, and I think as a result of that I made the right personal decision. And here we are now having this meta-discussion with people not having a clue. Welcome !
You seem to imply there was no communication, and I stopped the project out of the blue. That is a misrepresentation.
Nobody stepped up to take over maintainership, and I don't see anyone doing that now. But if someone wants to try, I can unarchive the project and restore the PRs and issues.
If not, the king is dead, long live the king!
What they should have done is tried to reach out to you before forking.
They included in RHEL and sold it as part of their product when it suited them, and now they have replaced it because it suited them. That's fine, I don't have to agree.
Changing the name space would have been problematic, as so many people use automation tools now to install package dependencies, rather than break their work because someone has zero intention of maintaining a project, they did the right thing and used the same namespace.
Had this been a case of RH disagreed with the developers direction or any factor around an active project, it would have been a shitty move, but considering the developer ignored any offers to help and let the project to fall into a stale un-maintained state, I don't see any grounds for him to throw his rattle out of the pram and blame RH here.
I assume people offering to help only wanted to see their own contributions merged.
I shouldn't be surprised people here take positions while not having been involved in the project or know the whole history.
In my opinion, stopping the project was the only sensible thing to do at this point. Red Hat replacing the tool with one of their own (which I wholeheartedly disagree with for various reasons) created a dead-end. It's the final blow to a dying project.
Wrt. Python 3 support, I simply did it because it was so easy to do, not because I thought this would be a game-changer. But hey, please do read into whatever fits your narrative :-)
This webpage listing the contents of the fc30 pcp-system-tools package: https://fedora.pkgs.org/30/fedora-updates-x86_64/pcp-system-...
lists a file called '/usr/bin/dstat'. The pcp-system-tools package obsoletes a package called 'dstat'. If you go to https://pkgs.org/download/dstat, and look under "Fedora 30," you get pcp-system-tools.
[Spoiler: 'yum install dstat' installs pcp-system-tools, which has a symlink /usr/bin/dstat -> /usr/libexec/pcp/bin/pcp-dstat.]
> That said I don't fault you for make a new tool that does all the new fancy things you mentioned above, I do think it's a little sketchy to make a new tool called dstat without at least asking here first. I know that when I hit Fedora 29 and did a yum install dstat and I get a bunch of pcp stuff I was pretty confused.
The way they have things aliased right now, if you type in `yum install dstat` you will get this new program (including all of its baggage).
A: "Whoa, there is no dstat in RHEL8? Customers are gonna complain."
B: "Yes, it's because it's Python 2 only and upstream is dead. Tell customers to use PCP"
A: "Srsly? Nobody thinks of the scripts? Besides, dstat output is so nice."
C: "Well, there is some toy example to print pcp data in dstat format."
A: "Do we really want to tell customers 'there is a toy example'?"
C: "Give me a day or two to pimp it up."
And then C got a bit carried away. :-)
And it's not like I have disappeared from the face of the earth. I am quite active on GitHub.
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