6 ms·

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 pro

by tedivm 7y ago

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 https://github.com/dagwieers/dstat/issues/156

deleted 7y ago
[deleted]
jsnell 7y ago
You've misunderstood. The "dstat" package was removed from Fedora, rather than have its contents replaced. The package containing the new program is called "pcp-dstat", so they already did everything you think they should have done.
- tmyklebu 7y ago
  What makes you think he misunderstood? What happens on fc30 when you 'yum install dstat' as he suggested? This webpage listing the contents of the fc30 pcp-system-tools package: https://fedora.pkgs.org/30/fedora-updates-x86_64/pcp-system-tools-4.3.2-1.fc30.x86_64.rpm.html 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 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.]
  - GauntletWizard 7y ago
    An alias to the replacement is not the same as silently replacing the package. Yes, the user who care will notice - it's a tool for sysadmins, and the ones worth their salt are already familiar with precisely this provision in package managers, and it's included for precisely this reason. There's always politics involved in replacing a tool, but they didn't steal his namespace - they made the decision to package their own alternative, and yes, that editorial decision does lie with the distribution.
- tedivm 7y ago
  To quote a comment from a dstat collaborator from the above linked thread- > 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).
dagwieers 7y ago
It didn't just slip their mind, they did not really care: https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 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.
- dralley 7y ago
  I totally agree that they should have left a note on the issue tracker - even if they thought it would go unread. However I think you're being a little unfair on this one point. >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.
  - dagwieers 7y ago
    Huh? Jumping to conclusions while not knowing all the facts. Please read up on the discussions that we had _after_ Red Hat made this decision. Their decision was made, end of discussion. 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 !
tedivm 7y ago
Apparently reusing the name without talking to the author was a conscious decision on their behalf- https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7
- appstateguy 7y ago
  meh. ultimately this is OSS. the maintainer was negligent. if you're not a good OSS maintainer, you don't deserve to maintain control. it's not reasonable to be indefinitely patient when the original author shows no initiative to maintain their project
  - bauerd 7y ago
    They didn't even try to contact the author?!
    - bonzini 7y ago
      dstat was basically presumed dead due to lack of upstream activity. I recall the internal discussion was something like 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. :-)
    - op00to 7y ago
      Why would you try to contact someone who's abandoned the project?
      - dagwieers 7y ago
        Maybe because it is the nice thing to do? And it's not like I have disappeared from the face of the earth. I am quite active on GitHub.
devnullbyte 7y ago
I disagree, they were right to use the same namespace and its questionable how you conflate that to stealing. If something is abandoned, how can you steal it? The project was dead, PR's and issues were ignored and the lack of Python 3 support was a huge issue (which the developer pathetically tried to shut down discussion over by releasing a python 3 port just hours before closing the project). 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.
- dagwieers 7y ago
  Nobody stepped up to maintain the project, not even Red Hat. Some people have offered help, and I have send out a few GitHub invitations to people that offered, but no takers. 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 :-)
  - deleted 7y ago
    [deleted]

by tedivm 7y ago

deleted 7y ago

[deleted]

jsnell 7y ago

You've misunderstood. The "dstat" package was removed from Fedora, rather than have its contents replaced. The package containing the new program is called "pcp-dstat", so they already did everything you think they should have done.

tmyklebu 7y ago
What makes you think he misunderstood? What happens on fc30 when you 'yum install dstat' as he suggested? This webpage listing the contents of the fc30 pcp-system-tools package: https://fedora.pkgs.org/30/fedora-updates-x86_64/pcp-system-tools-4.3.2-1.fc30.x86_64.rpm.html 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 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.]
- GauntletWizard 7y ago
  An alias to the replacement is not the same as silently replacing the package. Yes, the user who care will notice - it's a tool for sysadmins, and the ones worth their salt are already familiar with precisely this provision in package managers, and it's included for precisely this reason. There's always politics involved in replacing a tool, but they didn't steal his namespace - they made the decision to package their own alternative, and yes, that editorial decision does lie with the distribution.
tedivm 7y ago
To quote a comment from a dstat collaborator from the above linked thread- > 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).

dagwieers 7y ago

It didn't just slip their mind, they did not really care: https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 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.

dralley 7y ago
I totally agree that they should have left a note on the issue tracker - even if they thought it would go unread. However I think you're being a little unfair on this one point. >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.
- dagwieers 7y ago
  Huh? Jumping to conclusions while not knowing all the facts. Please read up on the discussions that we had _after_ Red Hat made this decision. Their decision was made, end of discussion. 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 !

tedivm 7y ago

Apparently reusing the name without talking to the author was a conscious decision on their behalf- https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7

appstateguy 7y ago
meh. ultimately this is OSS. the maintainer was negligent. if you're not a good OSS maintainer, you don't deserve to maintain control. it's not reasonable to be indefinitely patient when the original author shows no initiative to maintain their project
- bauerd 7y ago
  They didn't even try to contact the author?!
  - bonzini 7y ago
    dstat was basically presumed dead due to lack of upstream activity. I recall the internal discussion was something like 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. :-)
  - op00to 7y ago
    Why would you try to contact someone who's abandoned the project?
    - dagwieers 7y ago
      Maybe because it is the nice thing to do? And it's not like I have disappeared from the face of the earth. I am quite active on GitHub.

devnullbyte 7y ago

I disagree, they were right to use the same namespace and its questionable how you conflate that to stealing. If something is abandoned, how can you steal it? The project was dead, PR's and issues were ignored and the lack of Python 3 support was a huge issue (which the developer pathetically tried to shut down discussion over by releasing a python 3 port just hours before closing the project). 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.

dagwieers 7y ago
Nobody stepped up to maintain the project, not even Red Hat. Some people have offered help, and I have send out a few GitHub invitations to people that offered, but no takers. 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 :-)
- deleted 7y ago
  [deleted]