Hi kiasoc5, hi Attila Am Samstag, dem 26.08.2023 um 19:42 +0200 schrieb kias...@disroot.org: > On 2023-08-25 11:31, Attila Lendvai wrote: > > > I feel like the advantages of a email-based workflow nowadays is > > > more on the maintainer side of things (as managing large projects > > > is easier > > > > > > another thing worth pointing out here is that the harder it is to > > test a submitted patchset locally, the fewer non-committer reviews > > will happen. > > > > and if all the review work rests on the shoulders of the > > committers, then there'll be long response times on submissions, or > > straight out forgotten/ignored submissions (khm). especially if > > it's about some hw or some sw that none of the committers care > > about, or could test locally (e.g. Trezor support: > > https://issues.guix.gnu.org/65037 that > > doesn't even build in master). Do you mean that Trezor doesn't currently build on master or that this series doesn't build relative to master any longer? It'd be quite weird if it was the latter, but oh well. I'll review the series afterwards.
> I would like to hear from committers if non-committer reviews are > helpful, because I don't really know how or what I can comment on for > incoming patches on packages I'm not really familiar with. If you're not familiar with the package, on which grounds would you review the patch? This holds for committers and non-committers all the same; it's a main reason as to why I don't review many Emacs packages despite being in the Emacs team. My init.el is on the smaller side and only exercises a small portion of the emacs-xyz module. On the other hand, if you do have relevant information to add, please do so. For instance, if you know about the hardware or the software or even if you've only heard about some anti-feature such as telemetry, such information is valuable. If you want to nerd about the way we write ChangeLogs, that's also fine, and might save someone else the need to do so (or encourage them to do so as well, you win some, you lose some). > Also do "this builds and works locally" comments help? "Builds locally" not so much, unless it's a package that CI doesn't handle usually. "Works locally" should be qualified to distinguish it from simply "builds locally", but if you say something along the lines of "I've tested and ran the program; it works as I'd expect", you might be saving a committer some time and allow them to focus on other things. If there are no cosmetic flaws and the committers are aware that the package works fine for more than just a single person, they can fast track it more easily. OTOH, if you write "works locally" and no committer reads it – for any reason, really – the result will be the same as if you never wrote it. TL;DR: "Builds locally" helps maybe, but probably not. "Works locally" probably helps, but sometimes not. For cases in which "works locally" doesn't seem to help, you sadly have to check the CCs and add a committer who might look like they'd be interested in upstreaming the series :( Cheers
