Maintenance of top-level files

Simon Marchi simon.marchi@polymtl.ca
Fri Sep 10 14:35:35 GMT 2021


On 2021-09-10 12:58 a.m., Alan Modra via Gdb wrote:
> On Wed, Sep 08, 2021 at 09:23:49AM +0100, Andrew Burgess wrote:
>> My question then, is what are peoples thoughts on how these files
>> should be managed?
> 
> The question I take it really is:  Who has authority to approve
> patches, and at least some responsibility to respond to bug reports
> related to these files?
> 
> I don't think we (binutils + gdb) should take the position that these
> files are owned by gcc, and thus authority and responsibility fall to
> the listed gcc build machinery maintainers.  That doesn't seem fair or
> reasonable.  The situation with top level files is very different to
> say, libiberty, where binutils+gdb is unlikely to want changes that
> are completely uninteresting to gcc.  With top level config*, Make*,
> libtool.m4, lt* and so on we often want changes that aren't
> interesting to gcc, and vice versa.  A model where changes are
> installed first into one repository and then backported to the other
> makes sense, I think.

Agreed.  They generally are not too controversial changes anyway.

> So do we want someone appointed top-level build machinery maintainer
> in binutils+gdb?  If so, I nominate Simon Marchi if he's interested.
> Why Simon?  Because in digging through top-level logs, he's the most
> recent (2018) person to act as a maintainer of those files, commit
> d0ac1c4488.  Before that, there was Ralf Wildenhues in 2010.

I'm not sure I have enough knowledge about how the top-level build
machinery works.  Unless we starting having patches that are
particularly controversial, I think it's ok if all binutils and GDB
global maintainers can approve patches to the top-level.  We should
still make sure that patches that touch these files are sent to both
lists.

Simon


More information about the Gdb mailing list