On Aug 18 2023 10:43, Krzysztof Kozlowski wrote:

quoted

quoted

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.

quoted

quoted

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.