On Aug 18 2023 10:43, Krzysztof Kozlowski wrote: > >> For newcomers, OTOH, I would either recommend simple workflow or just > >> use b4. Why? Because if you cannot use git-send-email, then it means > >> your email setup will make your life difficult and adding maintainers to > >> existing patch won't help you. > > > > You've mentioned a "simple workflow" many times - could you please share more > > details on the steps you follow in your workflow for sending patches? > > I shared it on LKML few times already (and Rob's git send-email identity > is also on LKML), so one more time: > > https://github.com/krzk/tools/blob/master/linux/.bash_aliases_linux#L91 Thank you for sharing this - it is really neat indeed and you certainly don't need a step #2 with this method. However, I see areas for improvement in the alias: - Subsystem-specific mailing lists, maintainers, reviewers, and other roles are all marked as "To: " sans distinction via the alias whereas `add-maintainer.py` and `b4` both provide marking of lists as "Cc: " which seems aesthetically and semantically more pleasing. - Only `add-maintainer.py` allows for maintainers to be selectively in "To: " and "Cc: " for patches in a series depending on whether they are the maintainers for that particular patch or not. > >> This tool depends on the command line and shell interface of > >> scripts/get_maintainers.pl which is another reason why it might not be a > >> good idea. > > > > Could you please elaborate on why depending on the output of > > `get_maintainer.pl` is a bad idea? It's what everyone uses, no? > > No, because if interface changes you need to update two tools. But `b4 prep --auto-to-cc` also uses `get_maintainer.pl`! Also, in your previous email you said to "just use b4", which also depends on the command line and shell interface of `get_maintainers.pl`. Depending on `get_maintainer.pl` is therefore perfectly okay - there is no need to reinvent it or disregard it for whatever reasons. Thank you. Guru Das.
