Conversation
@mort @dm @marcan This has nothing to do with the platform, really. I've reported many (what I consider) critical bugs to Python where they've been sitting in the shiny Github bugtracker without any movement. Your patches are ignored NOT because they were sent via email -- there's just nobody looking at them (because they are on vacation, tired, burned out, sick, etc).
1
0
9
@ekuber @marcan he’s just jealous.
1
0
1
@ArneBab @ekuber @marcan We do have CI via patchwork, it just needs improvement and the Tested-By needs to be recorded in commits.

E.g. see https://patchwork.kernel.org/project/netdevbpf/patch/20230214211534.735718-5-pctammela@mojatatu.com/
0
1
1
@axboe @ljs @marcan to be honest, it'd be great if people with your profile *did* get involved more.
1
0
3
@axboe @ljs @marcan woops, hit send too soon! Was going to point out that calling out shite has to come from prolific people down.
And to behavior from maintainers/reviewers and cantankerous contributors alike!
0
0
3
@marcan @ljs I feel a bit called out (maybe I'm wrong) as I've been saying that "I learned to enjoy the struggle" and that I tend to enforce nitpicking comments (the "reverse xmas tree nonsense") particularly on newcomers these days.

Let me clarify again that I don't consider myself any sort of abusive masochist (is this even a thing in English?) which likes to put people through the pains he suffered, but the two things are strictly related to the end quality of the code that it is merged and how.

- clunky process make sure you check every part and make sure you know and think about what you're sending out and to who (and I still make a mistakes, so I know it's not all good). That said, I concur that a git push -f over the whole "format, edit cover letter, add receivers in" etc is simpler, even more for simple fixups. I don't see this happening easily though. In the subsystem I work the most there are at least 4 sub-maintainers maintaining their own trees and to get to a point where you can git push to a single tree it will take time to re-organize the whole subsystem workflow (not saying it's not possible, what I'm saying is that it's not a purely technical problem).

- nitpicking, even on style details, is for the sole sake of consistency of the code base. Some reviewers are annoying, some other try to phrase it in a way that sounds like a kinds suggestion, and I'm aware of the usual caveat of per-subsystem unwritten rules and personal preferences, which should be better handled I agree. You're free to use a styler if you like, nobody requires you to do so by hand so I don't get all this emphasis on "I'm gonna use clang-format for my subsystem", you're welcome to do so and everyone has her own formatting tools in place already (in the editor, in commit-hooks whatever). As others like @sailus pointed out, once you let a driver diverge (style wise) you will soon get other submitters copying whatever is there and confront review comments with "I copied it from xyz, why is fine for others but not me?". Most comments here do not seem to consider this a problem at all and I suspect there's an underestimation of how bad things could go when thousands (ok, maybe hundreds if you consider a big sub-system like media) of people messes with the same code base.

Again, thanks for bringing this up, but please stop the "us" versus "them" thing though.
1
0
3
@marcan @ljs @sailus and don't get me wrong, I recognize that no "abusive masochist" person would recognize himself as such :)
0
0
1