4 ms·

I've got a few patches in pkg-config[1]. That was the kind of contribution I like to do: small, improves behavior while removing code, very central and popular

I've got a few patches in pkg-config[1]. That was the kind of contribution I like to do: small, improves behavior while removing code, very central and popular tool... I gave up contributing after being ignored[2]. Around the same time, other people posting patches to the mailing list were also ignored. Sad. [1] https://gitlab.freedesktop.org/pkg-config/pkg-config/-/commit/c53385b5dbd25844faa89b1c8297d61ab05ed6ef https://gitlab.freedesktop.org/pkg-config/pkg-config/-/commi... https://bugs.freedesktop.org/show_bug.cgi?id=98215 https://bugs.freedesktop.org/show_bug.cgi?id=98215 [2] https://lists.freedesktop.org/archives/pkg-config/2018-May/001100.html https://lists.freedesktop.org/archives/pkg-config/2018-May/0...

mort96 4y ago
I can't describe how much I hate purely e-mail merge requests. If your e-mail doesn't get a response in a week or so, everyone will have forgotten about it and the relevant people have gotten 1000 new e-mail since yours. With something like gitlab/github/sr.ht/gogs/gitea/anything else, your MR will remain in the relatively short (compared to an inbox with all incoming e-mail) list of open merge requests, clearly visible in a web interface. Issues you create are the same way. I very, very rarely experience having my MR or issue completely ignored for years with projects which use a web issue/MR tracker, except for with unmaintained single-person hobby projects. But it seems to be the rule with e-mail, even for actively maintained serious projects.
- qbasic_forever 4y ago
  Email is a fault tolerant communication. If you aren't getting a response then... reply back. If you still aren't getting a response then the community isn't interested at the moment. This is how open source works and how a small collection of maintainers can keep their sanity and avoid burnout in the face of thousands of people demanding time and attention. No one can possibly juggle all of the requests and such like yours. Creating an issue, sending a pull request, etc. costs the maintainer time and that time is incredibly valuable.
  - mort96 4y ago
    The maintainers' time is valuable, yes, which is why it's good to have a system where they can get to something in their own time that doesn't rely on contributors spamming on a mailing list.
  - arp242 4y ago
    pkg-config hardly has "thousands of people demanding time and attention". It doesn't seem to require that much attention.
- aseipp 4y ago
  I used email workflows before. And on a project I used to work on (Glasgow Haskell Compiler), people would originally just attach .patch files to issues in the bug tracker we used, called Trac. This was how it worked for years, and while it did work, it had some similar outcomes: tons of patches that just silently were forgotten. The only saving grace is that I had a search macro setup that could just find "WITH attachment AND status = 'Ready for Review'" but of course that requires people knowing to fill out the forms properly to specify that this issue has a patch and that it fixes the problem and it's ready for review. Why would someone who spent 2 hours writing a bugfix know this? In contrast I have hundreds of hours in this realm so it's second nature. But it's a joke to think it's intimately or immediately familiar. Occasionally someone would email me and ask to look at a patch and ask if they did something wrong, which is why it got ignored. Ignoring any actual technical complaints, probably 80% of the time my answer was "Actually, I just missed this one" or "It didn't have the "patch" field set so my search didn't find it." I had to do this annoyingly often; it was annoying. I didn't blame anyone for it however. But pretending it's not annoying is also a lie. Honestly I don't think GitHub is the end-all of project contribution and it still has some really annoying flaws. I don't like the branch-merge workflow; I prefer non-branch-based merge workflows, which email does provide. But beyond that there are almost no advantages to it in my experience. I also suspect that there's a reinforcement mechanism going on these days. People who think email is good for this task already love email. They think it's amazing. In some sense I can agree, and in the past, it really was amazing. But less and less people even "bother" with email in my experience than ever before; to them, it's a necessary evil where they get shit shoveled at them 24/7/365, all so that they can pluck a single piece of information from the shitheap of trash; where they can go to reset their account passwords. It is not a bright shining feature of the internet to them.
- saurik 4y ago
  > I very, very rarely experience having my MR or issue completely ignored for years with projects which use a web issue/MR tracker, except for with unmaintained single-person hobby projects. I mean, it might not be "completely ignored", but after the initial triage by a maintainer I have definitely experienced extremely large projects going years ignoring something from the core while occasionally random third parties show up to cry. The worst part is that if people stop actively commenting with "me too"--even if an official developer chastises them for it every time--the issue often gets auto-locked/deleted. (Or, in the case of a pull request, the code will rot to the point where something auto-closes it due to it no longer merging.)
synergy20 4y ago
for one thing, pkg-config really should do -isystem instead of -I for headers, -isystem helps editor to not bother checking them for syntax conformity, otherwise my vi sometimes produces thousands of lines of warnings for those standard header files, and I have to add isystem to them manually. cmake smartly converts pkg-config's -I to -isystem nowadays, which is great.
- saurik 4y ago
  That really seems like it should be the purview of the build system (such as cmake), not pkg-config. The flags provided by pkg-config should be as simple and obvious and easy to reason about and as portable as possible (and, worst case, as consistent as possible so you can convert it to some different flag format, as arguably is being done there by cmake). The goal of -isystem has nothing to do with syntax highlighting, even if your text editor may also be reading it (though I am unsure from where, lol)... it has non-trivial effects on things like #include path ordering.
  - synergy20 4y ago
    make sense,thanks
bjourne 4y ago
Back in the day, I also posted a bunch of patches to pkg-config, but all of them were ignored by the maintainer(s). I'm not surprised people eventually started creating their own rewrites because the project was very poorly run.

mort96 4y ago

I can't describe how much I hate purely e-mail merge requests. If your e-mail doesn't get a response in a week or so, everyone will have forgotten about it and the relevant people have gotten 1000 new e-mail since yours. With something like gitlab/github/sr.ht/gogs/gitea/anything else, your MR will remain in the relatively short (compared to an inbox with all incoming e-mail) list of open merge requests, clearly visible in a web interface. Issues you create are the same way. I very, very rarely experience having my MR or issue completely ignored for years with projects which use a web issue/MR tracker, except for with unmaintained single-person hobby projects. But it seems to be the rule with e-mail, even for actively maintained serious projects.

qbasic_forever 4y ago
Email is a fault tolerant communication. If you aren't getting a response then... reply back. If you still aren't getting a response then the community isn't interested at the moment. This is how open source works and how a small collection of maintainers can keep their sanity and avoid burnout in the face of thousands of people demanding time and attention. No one can possibly juggle all of the requests and such like yours. Creating an issue, sending a pull request, etc. costs the maintainer time and that time is incredibly valuable.
- mort96 4y ago
  The maintainers' time is valuable, yes, which is why it's good to have a system where they can get to something in their own time that doesn't rely on contributors spamming on a mailing list.
- arp242 4y ago
  pkg-config hardly has "thousands of people demanding time and attention". It doesn't seem to require that much attention.
aseipp 4y ago
I used email workflows before. And on a project I used to work on (Glasgow Haskell Compiler), people would originally just attach .patch files to issues in the bug tracker we used, called Trac. This was how it worked for years, and while it did work, it had some similar outcomes: tons of patches that just silently were forgotten. The only saving grace is that I had a search macro setup that could just find "WITH attachment AND status = 'Ready for Review'" but of course that requires people knowing to fill out the forms properly to specify that this issue has a patch and that it fixes the problem and it's ready for review. Why would someone who spent 2 hours writing a bugfix know this? In contrast I have hundreds of hours in this realm so it's second nature. But it's a joke to think it's intimately or immediately familiar. Occasionally someone would email me and ask to look at a patch and ask if they did something wrong, which is why it got ignored. Ignoring any actual technical complaints, probably 80% of the time my answer was "Actually, I just missed this one" or "It didn't have the "patch" field set so my search didn't find it." I had to do this annoyingly often; it was annoying. I didn't blame anyone for it however. But pretending it's not annoying is also a lie. Honestly I don't think GitHub is the end-all of project contribution and it still has some really annoying flaws. I don't like the branch-merge workflow; I prefer non-branch-based merge workflows, which email does provide. But beyond that there are almost no advantages to it in my experience. I also suspect that there's a reinforcement mechanism going on these days. People who think email is good for this task already love email. They think it's amazing. In some sense I can agree, and in the past, it really was amazing. But less and less people even "bother" with email in my experience than ever before; to them, it's a necessary evil where they get shit shoveled at them 24/7/365, all so that they can pluck a single piece of information from the shitheap of trash; where they can go to reset their account passwords. It is not a bright shining feature of the internet to them.
saurik 4y ago
> I very, very rarely experience having my MR or issue completely ignored for years with projects which use a web issue/MR tracker, except for with unmaintained single-person hobby projects. I mean, it might not be "completely ignored", but after the initial triage by a maintainer I have definitely experienced extremely large projects going years ignoring something from the core while occasionally random third parties show up to cry. The worst part is that if people stop actively commenting with "me too"--even if an official developer chastises them for it every time--the issue often gets auto-locked/deleted. (Or, in the case of a pull request, the code will rot to the point where something auto-closes it due to it no longer merging.)

synergy20 4y ago

for one thing, pkg-config really should do -isystem instead of -I for headers, -isystem helps editor to not bother checking them for syntax conformity, otherwise my vi sometimes produces thousands of lines of warnings for those standard header files, and I have to add isystem to them manually. cmake smartly converts pkg-config's -I to -isystem nowadays, which is great.

saurik 4y ago
That really seems like it should be the purview of the build system (such as cmake), not pkg-config. The flags provided by pkg-config should be as simple and obvious and easy to reason about and as portable as possible (and, worst case, as consistent as possible so you can convert it to some different flag format, as arguably is being done there by cmake). The goal of -isystem has nothing to do with syntax highlighting, even if your text editor may also be reading it (though I am unsure from where, lol)... it has non-trivial effects on things like #include path ordering.
- synergy20 4y ago
  make sense,thanks

bjourne 4y ago

Back in the day, I also posted a bunch of patches to pkg-config, but all of them were ignored by the maintainer(s). I'm not surprised people eventually started creating their own rewrites because the project was very poorly run.