3 ms·

The scenario here is "The <Operating System> package is out of date, why have you not refreshed it yet." What should the Taskwarrior developers do to fix that?

• notacoward 11y ago
  Perhaps. Automatically putting the onus on the developer would be wrong, but so is automatically putting the onus on the packager. It's a collaborative process. Blaming the packager represents exactly the same sense of entitlement that the author complains about among users demanding features. Packagers are often volunteers too, doing what they do in their spare time. Usually they're glad to push out a package for a developer who is doing their best to facilitate the process themselves, but blindly passing the buck doesn't fit that description.
  • dalke 11y ago
    I believe I understand your point. However, "What should the Taskwarrior developers do to fix that?" Let's suppose I have a package, which I update quarterly, and I have a public announcements list, set up for people to be notified about new releases, and I answer support emails. Someone sends me an email saying the version they get through Fink is a year out of date. What is my responsibility as a developer? Do I contact the Fink maintainer myself? Or is it more effective for a user to ask for help? I can totally understand the argument that I should track down these people and ask them to update the package. But I can also understand the argument that I've set up an announcement list, and provide support, so what more do maintainers need? Yes, the personal touch helps, and maintainers get little feedback or support. But at this point it isn't really "packaging" but "interfacing with third-party distributors". You made the comment 'Anyone who can't do that, or isn't willing to, can't claim to have "learned all they can" about software delivery,'. Going back to my hypothetical, if all of the other package distributors are up to date (RedHat, Anaconda, Homebrew, ...) and only Fink is not, how does the failure with Fink show that I haven't learned all I can about software delivery? Really, however, we don't know the history of why that comment is there. It could be that they tried several times to update their package until finally giving up. If that were true, then they "learned" it was best to let the package users demand updates, not the suppliers.
    • notacoward 11y ago
      > I can totally understand the argument that I should track down these people and ask them to update the package. You shouldn't even need to track them down. If it's a packaging and distribution channel you've used before, you should already be in communication with the package maintainer. Yes, it's possible that there could be a problem with a package you didn't know existed, but such cases are very much the exception. Even then, the right thing to do would probably be to suggest a better-supported alternative and/or introduce yourself to the people maintaining that package. > It could be that they tried several times to update their package It could be. We're giving rather a lot of benefit of the doubt to the developers, aren't we? Why not give some to the packagers? They have their own standards they need to maintain, for the sake of their users. As often as not, packaging delays are the result of developers just throwing stuff over the wall for someone else to fix up. We need to proactively fight against that tendency. > they "learned" it was best to let the package users demand updates, not the suppliers. Again, it's not either/or. Both developers and packagers need to be part of that conversation. Neither gets to walk away and say it's somebody else's problem. As always in open source, collaboration is critical.
      • dalke 11y ago
        > Yes, it's possible that there could be a problem with a package you didn't know existed My limited experience may well be the exception, but I'll bring it up anyway. I wrote an RSS module in 2003. Someone else later added it to PyPI, the Python indexer. It has also been distributed by multiple packaging systems. I had no clue. No packager has ever said anything about it to me. Looking now, it's distributed by Gentoo, Debian, Slackware, Ubuntu, and more. It's also used in PyMediaRSS2Gen, dilbert-rss, and loads more packages. It took me two days to write that package, and another few days of maintenance in the 12 years. Until now I believed this hand-off mechanism, mediated by PyPI, was the way to go. Because it would take me much longer to interact with all of those distributions than to write the code in the first place! > Why not give some [doubt] to the packagers? Because the statement you made earlier, "They need to work with package maintainers, fixing (and not re-creating) problems that make packaging difficult. Anyone who can't do that, or isn't willing to, can't claim to have "learned all they can" about software delivery, as I see in the first paragraph of the other Taskwarrior article posted today." gave no doubt to the developers.