[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72mH+t0-4Vz1O2dXts8rUzkW9XT2enz+KERbuXe+SokvCg@mail.gmail.com>
Date: Fri, 6 Dec 2024 23:42:24 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: guilherme giacomo simoes <trintaeoitogc@...il.com>
Cc: a.hindborg@...nel.org, alex.gaynor@...il.com, aliceryhl@...gle.com,
benno.lossin@...ton.me, bjorn3_gh@...tonmail.com, boqun.feng@...il.com,
fujita.tomonori@...il.com, gary@...yguo.net, linux-kernel@...r.kernel.org,
ojeda@...nel.org, rust-for-linux@...r.kernel.org, tahbertschinger@...il.com,
tmgross@...ch.edu, walmeida@...rosoft.com, wcampbell1995@...il.com
Subject: Re: [PATCH] rust: macros: add authors
On Fri, Dec 6, 2024 at 10:19 PM guilherme giacomo simoes
<trintaeoitogc@...il.com> wrote:
>
> And how in the first option I would need found all modules that have the author
> tags and I would need change the code (from `author: "author"` to `author:
> ["author"])`, I was think that is the best don't change in a thing that is
> already work well.
I understand what you mean, but changing a few existing lines here and
there is fine. There aren't that many modules out there. If we are
going to change this, then the best time is now. Backporting should
not be too bad either.
In any case, in general, I would focus in deciding what we want to end
up with, and then we can discuss how to get there (assuming there was
a problem getting there).
> - Accepting several "author" fields and append them all into a list.
> because in the modules the developers would need a several author field if the
> module is development for several author. And the module! macro would grow a lot.
> Like:
> author: guilherme,
> author: miguel,
> author: another_poor_developer,
> ....
Sorry, I am not sure I understand what you mean. Yes, the idea of this
option is to repeat one line per author, but that is not a big deal: C
modules do that already.
> I make this change because, the for() would need repeat for the alias and for
> the authors and for avoid unnecessary code repetition I create the
> emit_arr_str() function.
In general, it is best to mention it in the commit message or, even
better, do the cleanup in another patch. Having said that, I am not
sure I would introduce the function -- we are not really saving lines
and it is yet one more function to read.
Thanks!
Cheers,
Miguel
Powered by blists - more mailing lists