This session was led by Jonathan "jrnieder" Nieder. Supporting cast: brian
"bmc" carlson, Emily Shaffer, Johannes "Dscho" Schindelin, CB Bailey,
Junio Hamano, and Matthias Aßauer.
Notes:
1. Been interested in this for a long time
2. Dscho said he’s not able to follow everything on the mailing list
1. if you have just one patch you send, reply-all works okay
2. mailing list works reasonably well if you’re someone like Junio, working
on it full time, has good mail filters, keeps up to date with everything
3. If you’re in-between, does not work well
3. Lessley mentioned in the Diversity & Inclusion context:
1. you send your patch,
2. want to have a solid review
3. want guidance where to go from here
4. timely feedback
5. want to know where the patch stands
6. What happens: guilt-based workflow, where reviewers reply much later
after being prodded
4. bmc: I want some way to track patches
1. What have I reviewed before and what have I not reviewed since last
time?
2. Emily: most of this exists in patchwork. Our intern Raxel Gutierrez did
work on that this summer. Alas, that doesn’t show up on
patchwork.kernel.org because it’s using patchwork 2.x and the features
are in 3.x
3. https://youtu.be/24dL8yqhYNg
5. bmc: I want some kind of bug tracking system
1. In git-lfs when I need a git feature, people are happy to send a patch,
there’s no point of coordination for this. Don’t know where to send a
patch, don’t know where to send a bug report
2. debbugs works okay, has a huge spam problem, but it works fine; email
based
3. Emily: Every time this comes up I go oh $&!& because this is
perennially a source of dispute. I don’t care what tracker we use, just
want one
4. Dscho: everyone else is caught in the crossfire between jrnieder and
me.
5. CB: Is there an option that makes you both equally miserable?
6. bmc: Could we get kernel.org to host something?
7. jrnieder: there’s a bugzilla instance at bugzilla.kernel.org, which
might satisfy CB’s criterion
8. bmc: I want to have whatever we use send out to the list. That would
avoid conversations going on without people in the mailing list centric
workflow being aware of it. If we are all using a GitHub/GitLab based
workflow then that’s not required
9. Emily: +1, great point
10. jrnieder: Sounds like we have some common ground so seems worth
starting a mailing list thread
11. Junio: As long as I’m not the person operating the bug tracker, I’m
happy :)
12. Dscho: Is it important to you that it sends things to the mailing list?
13. Junio: Not really. The extra tracking conversations are not as
important to me. I think it’s a feature that if someone requests a
feature and nothing happens for a while that it no longer produces
overhead for people is a useful feature. That kind of old filtering
feature is sometimes valuable.
14. jrnieder: in a bug tracker, triage + common sense of priorities is very
useful. Experiences in JGit bugzilla vs the Debian bugtracker (the
latter is better curated)
15. brian: I’m happy to volunteer to do some triage on the bugtracker. If
other people will help out and contribute, happy to do that
16. I’m also happy to work with kernel.org admins to get this set up for us
if that’s what we want
17. people would expected to be kind+helpful in interactions there, can’t
expect it to devolve into a cesspit
18. Matthias: I’m happy to help with triage too
