Maintenance of top-level files

Maintenance of top-level files

[Andrew Burgess]

Hi!

I wonder what the policy is these days regarding how the top level
files are maintained, e.g. Makefile.def and configure.ac?

I know once upon a time these files were maintained in the gcc
repository and then back-ported periodically to binutils-gdb, however,
as far as I can see the last attempt to sync from gcc was this commit:

  commit f948b2de97884bfb4e5fc11d40a6bea9e0b096ae
  Date:   Wed May 29 12:43:42 2019 +0100

      Sync top level files with versions from gcc.

Which was over 2 years ago.  This commit was then quickly reverted:

  commit e3f56a99f66298bb505d0426950b9716a853a5df
  Date:   Thu May 30 11:17:19 2019 +0100

      Revert "Sync top level files with versions from gcc."

Since then there's been 30+ patches to the top level files.

My question then, is what are peoples thoughts on how these files
should be managed?  Are we going to try and get back in step with gcc?
Or are we happy to continue to diverging?

Thanks,
Andrew

Re: Maintenance of top-level files

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

On 08 Sep 2021 09:23, Andrew Burgess wrote:
> I wonder what the policy is these days regarding how the top level
> files are maintained, e.g. Makefile.def and configure.ac?
> 
> I know once upon a time these files were maintained in the gcc
> repository and then back-ported periodically to binutils-gdb, however,
> as far as I can see the last attempt to sync from gcc was this commit:
> 
>   commit f948b2de97884bfb4e5fc11d40a6bea9e0b096ae
>   Date:   Wed May 29 12:43:42 2019 +0100
> 
>       Sync top level files with versions from gcc.
> 
> Which was over 2 years ago.  This commit was then quickly reverted:
> 
>   commit e3f56a99f66298bb505d0426950b9716a853a5df
>   Date:   Thu May 30 11:17:19 2019 +0100
> 
>       Revert "Sync top level files with versions from gcc."
> 
> Since then there's been 30+ patches to the top level files.
> 
> My question then, is what are peoples thoughts on how these files
> should be managed?  Are we going to try and get back in step with gcc?
> Or are we happy to continue to diverging?

afaik, it's still "gcc first".  when i commit changes to the top-level files,
it's the same git commit (using `git am`), not a blank "sync files".  i think
a bunch of the other ones are the same way.

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=17af39e1c0e590f4cb13d672c9ee850e871164ab
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9cc11ab5bf10c6f7494f6015769cf81b6988317f
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Maintenance of top-level files

[Alan Modra]

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.

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.

> Are we going to try and get back in step with gcc?

I think we should try to do that.  

-- 
Alan Modra
Australia Development Lab, IBM

Re: Maintenance of top-level files

[Simon Marchi]

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