Re: [PATCH v2 0/1] Add add-maintainer.py script

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux