There cannot be a more clear report than that, a one line describing the issue in a clear and concise way, and even pointing the lines with the problem. It would take 10 seconds to confirm that bug.
But no, not following the dumb, forced template that would have 5 times more noise, useless data and explanations, immediately results in closing a perfectly good bug report, treating contributors like idiots that cannot open a good issue. Zero flexibility. It takes more time to get that text to paste it than read the single line explaining the problem.
I like that the nixpkgs repo suggests an issue template but many of us can figure out when some of those points can be excluded because they would not contribute to a clear report, and we are not shut down for that.
I am done with those maintainers and I am happy having found Nix for almost all of my packages. Unfortunately I cannot get rid of it completely from my system just yet. (Somebody please add pandoc-crossref to the binary cache. I would if I knew how to do it.)
I do agree with you that its great the nixpkgs maintainers are amazing when it comes to flexibility with github issues. Its great to point that out here like you did. But I really don’t think its fair to insult or poke at other open source projects for having regulations to improve their own maintenance burden. I don’t know the history and reasoning behind homebrew having such rules, but I’m willing to believe they have good reasons. We all work in open source and know how thankless of a job that can be. Sometimes that means having to prioritize your time by adding such rules for closing issues.
just add a packaging request issue , if there is not one already.
Or try it yourself, some things are easy to package, others harder. There is always plenty of help available , if you willing to put the effort in a learn, people will help you learn, because they put the effort in and others taught them!
I’m going to guess that many requests and bugs they cannot successfully reproduce on their own systems, they have 1000’s of users, all with different states on their machines, OS versions and patch levels. A tragic case of ‘it works on my machine syndrome’.
I don’t know how many humans maintain it, but i can tell you those humans will burn out, and the more they burn out, the more stonewalling you’ll see.
This is a guess, it’s more likely the just don’t like 1 line bug reports like … ‘NOT WORKING, YOU FIX NOW’
I really hope it’s the latter, because if it’s the former, i feel sorry for them, and there’s not thing i can do to help them make their users/customers successful with it.
Oh, I know, but it needs almost 4 GB of space just to install all the dependencies to compile it:
$ nix-env --dry-run -iA nixpkgs.haskellPackages.pandoc-crossref
(dry run; not doing anything)
installing 'pandoc-crossref-0.3.12.1'
these paths will be fetched (343.34 MiB download, 3979.63 MiB unpacked):
While the brew install is a 40 MiB binary download, and that’s why I still install it with brew.
It would be great if pandoc-crossref is available also as a binary, because it is one of the most important filters for pandoc (which is in the binary cache). But I don’t know how to move pandoc-crossref from the haskellPackages set to the top level packages, or I would send a PR.
