On automated commits

On automated commits

[Sam James via Gdb]

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

Hi!

This was reported at
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 and Nick agreed
it's worth discussing on the ML.

Currently, binutils-gdb.git gets nightly commits to each active release
branch and master.

This is a bit noisy - especially so for the release branches where
it makes it hard to see if there's a new commit to backport downstream,
obfuscates git log, and also as pointed out in the PR, consumes disk
space forever.

On the PR, mjw suggests using gnulib's git-version-gen - which is a
solution I like the idea of (I have some draft to implement it for
Valgrind too) instead of automated commits to bump the version.

Nick also then says:
> I do like the idea of the configure file generating the bfd/version.h file
> automatically however, so if someone wants to write a potential patch that
> would be great.

Rostislav on the PR seems he may be up for working on it, but if he
can't, I might be able to when I'm less busy.

Thoughts?

thanks,
sam

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

Re: On automated commits

[Jan Beulich via Gdb]

On 25.06.2024 01:17, Sam James wrote:
> This was reported at
> https://sourceware.org/bugzilla/show_bug.cgi?id=31881 and Nick agreed
> it's worth discussing on the ML.
> 
> Currently, binutils-gdb.git gets nightly commits to each active release
> branch and master.
> 
> This is a bit noisy - especially so for the release branches where
> it makes it hard to see if there's a new commit to backport downstream,
> obfuscates git log, and also as pointed out in the PR, consumes disk
> space forever.
> 
> On the PR, mjw suggests using gnulib's git-version-gen - which is a
> solution I like the idea of (I have some draft to implement it for
> Valgrind too) instead of automated commits to bump the version.

I, too, was wondering whether these automatic updates couldn't be done
away with. Just one remark on generating from configure: Please don't
leave out the possibility of people like me not building directly from
the git tree, but from "snapshots" thereof, i.e. a case where the most
recent commit wouldn't be possible to establish from the tree at hand.
Maybe it's enough to cater for this by not doing anything when the
target file already exists (as would also be the case in builds from
e.g. the tarball); making the file in the course of taking the
"snapshot" is of course easily possible.

As to "most recent commit", just to mention it: Commits can linger in
people's trees for a long time, so when eventually pushed at least the
authoring date can be pretty misleading.

Jan

Re: On automated commits

[Tom Tromey via Gdb]

Sam> Nick also then says:
>> I do like the idea of the configure file generating the bfd/version.h file
>> automatically however, so if someone wants to write a potential patch that
>> would be great.

Sam> Rostislav on the PR seems he may be up for working on it, but if he
Sam> can't, I might be able to when I'm less busy.

Sam> Thoughts?

I personally have never liked these automated commits, and I can't
recall ever using the date they provide.

I also don't believe these dates are used here at AdaCore.

So +1 from me for removing these.

thanks,
Tom

Re: On automated commits

[Fangrui Song]

On Wed, Jun 26, 2024 at 10:41 AM Tom Tromey <tromey@adacore.com> wrote:
>
> Sam> Nick also then says:
> >> I do like the idea of the configure file generating the bfd/version.h file
> >> automatically however, so if someone wants to write a potential patch that
> >> would be great.
>
> Sam> Rostislav on the PR seems he may be up for working on it, but if he
> Sam> can't, I might be able to when I'm less busy.
>
> Sam> Thoughts?
>
> I personally have never liked these automated commits, and I can't
> recall ever using the date they provide.
>
> I also don't believe these dates are used here at AdaCore.
>
> So +1 from me for removing these.
>
> thanks,
> Tom

+1 from me for removing "Automatic date update in version.in" commits.

They are a distraction when investigating the history in the bfd/
directory `git log -- bfd/`.

Re: On automated commits

[Joel Brobecker via Gdb]

> I personally have never liked these automated commits, and I can't
> recall ever using the date they provide.
> 
> I also don't believe these dates are used here at AdaCore.
> 
> So +1 from me for removing these.

Same here.

I know that some people found them useful, but I don't remember why
unfortunately. Hopefully we move forward with a proposal to remove
those nightly commits, and the people who depended on them can
explain their needs and we can meet those needs in a different way.

-- 
Joel

Re: On automated commits

[Alan Modra via Gdb]

On Wed, Jun 26, 2024 at 11:17:04AM -0700, Joel Brobecker wrote:
> > I personally have never liked these automated commits, and I can't
> > recall ever using the date they provide.
> > 
> > I also don't believe these dates are used here at AdaCore.
> > 
> > So +1 from me for removing these.
> 
> Same here.
> 
> I know that some people found them useful, but I don't remember why
> unfortunately.

The date is useful when looking at bug reports from people who might
be building from development sources.  It also becomes part of the
libbfd.so name for anyone building and installing development
binutils.  We don't make any API promises regarding libbfd, so it is
more important than usual to pick up the correct libbfd.

-- 
Alan Modra

Re: On automated commits

[H.J. Lu via Gdb]

The auto commit script can skip date update if there are no changes
in program sources.

On Thu, Jun 27, 2024, 9:33 AM Alan Modra <amodra@gmail.com> wrote:

> On Wed, Jun 26, 2024 at 11:17:04AM -0700, Joel Brobecker wrote:
> > > I personally have never liked these automated commits, and I can't
> > > recall ever using the date they provide.
> > >
> > > I also don't believe these dates are used here at AdaCore.
> > >
> > > So +1 from me for removing these.
> >
> > Same here.
> >
> > I know that some people found them useful, but I don't remember why
> > unfortunately.
>
> The date is useful when looking at bug reports from people who might
> be building from development sources.  It also becomes part of the
> libbfd.so name for anyone building and installing development
> binutils.  We don't make any API promises regarding libbfd, so it is
> more important than usual to pick up the correct libbfd.
>
> --
> Alan Modra
>

RE: On automated commits

[Jiang, Haochen via Gdb]

> -----Original Message-----
> From: Alan Modra <amodra@gmail.com>
> Sent: Thursday, June 27, 2024 9:32 AM
> To: Joel Brobecker <brobecker@adacore.com>
> Cc: Tom Tromey <tromey@adacore.com>; Sam James <sam@gentoo.org>;
> binutils@sourceware.org; gdb@sourceware.org; rostiprodev@gmail.com
> Subject: Re: On automated commits
> 
> On Wed, Jun 26, 2024 at 11:17:04AM -0700, Joel Brobecker wrote:
> > > I personally have never liked these automated commits, and I can't
> > > recall ever using the date they provide.
> > >
> > > I also don't believe these dates are used here at AdaCore.
> > >
> > > So +1 from me for removing these.
> >
> > Same here.
> >
> > I know that some people found them useful, but I don't remember why
> > unfortunately.
> 
> The date is useful when looking at bug reports from people who might
> be building from development sources.  It also becomes part of the

Yes, dates are needed when something went wrong for trunk. It will
show when it breaks.

For release branch, we could ease the frequency for date change.

Thx,
Haochen

> libbfd.so name for anyone building and installing development
> binutils.  We don't make any API promises regarding libbfd, so it is
> more important than usual to pick up the correct libbfd.
> 
> --
> Alan Modra

Re: On automated commits

[Sam James via Gdb]

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

Alan Modra <amodra@gmail.com> writes:

> On Wed, Jun 26, 2024 at 11:17:04AM -0700, Joel Brobecker wrote:
>> > I personally have never liked these automated commits, and I can't
>> > recall ever using the date they provide.
>> > 
>> > I also don't believe these dates are used here at AdaCore.
>> > 
>> > So +1 from me for removing these.
>> 
>> Same here.
>> 
>> I know that some people found them useful, but I don't remember why
>> unfortunately.
>
> The date is useful when looking at bug reports from people who might
> be building from development sources.  It also becomes part of the
> libbfd.so name for anyone building and installing development
> binutils.  We don't make any API promises regarding libbfd, so it is
> more important than usual to pick up the correct libbfd.

I think we should be able to arrange for it to pop up in --version &
SONAME but this is a good point I'd not thought of wrt ABI.

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

Re: On automated commits

[Paul Koning via Gdb]

> On Jun 26, 2024, at 9:32 PM, Alan Modra <amodra@gmail.com> wrote:
> 
> On Wed, Jun 26, 2024 at 11:17:04AM -0700, Joel Brobecker wrote:
>>> I personally have never liked these automated commits, and I can't
>>> recall ever using the date they provide.
>>> 
>>> I also don't believe these dates are used here at AdaCore.
>>> 
>>> So +1 from me for removing these.
>> 
>> Same here.
>> 
>> I know that some people found them useful, but I don't remember why
>> unfortunately.
> 
> The date is useful when looking at bug reports from people who might
> be building from development sources.  

So why not have the build procedure pick up the last commit date, if building in a Git sandbox?  That's easy enough to arrange.  Similarly, it could pick up the identifier (SHA hash) of that last commit to make it entirely unambiguous.

	paul

Re: On automated commits

[Alan Modra via Gdb]

On Thu, Jun 27, 2024 at 09:23:20AM -0400, Paul Koning wrote:
> 
> 
> > On Jun 26, 2024, at 9:32 PM, Alan Modra <amodra@gmail.com> wrote:
> > 
> > On Wed, Jun 26, 2024 at 11:17:04AM -0700, Joel Brobecker wrote:
> >>> I personally have never liked these automated commits, and I can't
> >>> recall ever using the date they provide.
> >>> 
> >>> I also don't believe these dates are used here at AdaCore.
> >>> 
> >>> So +1 from me for removing these.
> >> 
> >> Same here.
> >> 
> >> I know that some people found them useful, but I don't remember why
> >> unfortunately.
> > 
> > The date is useful when looking at bug reports from people who might
> > be building from development sources.  
> 
> So why not have the build procedure pick up the last commit date, if building in a Git sandbox?  That's easy enough to arrange.  Similarly, it could pick up the identifier (SHA hash) of that last commit to make it entirely unambiguous.

I wasn't saying the way we do things now is the only way, just
explaining why the date is useful.  "git show -s --oneline @{u}" or
similar would be good too, but let's make sure we report upstream
commits not local ones.

-- 
Alan Modra

Re: On automated commits

[Jens Remus via Gdb]

Am 27.06.2024 um 15:43 schrieb Alan Modra:
> On Thu, Jun 27, 2024 at 09:23:20AM -0400, Paul Koning wrote:
>> So why not have the build procedure pick up the last commit date, if building in a Git sandbox?  That's easy enough to arrange.  Similarly, it could pick up the identifier (SHA hash) of that last commit to make it entirely unambiguous.
> 
> I wasn't saying the way we do things now is the only way, just
> explaining why the date is useful.  "git show -s --oneline @{u}" or
> similar would be good too, but let's make sure we report upstream
> commits not local ones.

@{u} refers to the tracking branch. In my setup that is not the upstream 
Binutils repository but my personal internal fork.

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303) and z/VSE Support
+49-7031-16-1128 Office
jremus@de.ibm.com

IBM

IBM Deutschland Research & Development GmbH; Vorsitzender des 
Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der 
Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/

Re: On automated commits

[John Baldwin via Gdb]

On 6/27/24 6:43 AM, Alan Modra via Gdb wrote:
> On Thu, Jun 27, 2024 at 09:23:20AM -0400, Paul Koning wrote:
>>
>>
>>> On Jun 26, 2024, at 9:32 PM, Alan Modra <amodra@gmail.com> wrote:
>>>
>>> On Wed, Jun 26, 2024 at 11:17:04AM -0700, Joel Brobecker wrote:
>>>>> I personally have never liked these automated commits, and I can't
>>>>> recall ever using the date they provide.
>>>>>
>>>>> I also don't believe these dates are used here at AdaCore.
>>>>>
>>>>> So +1 from me for removing these.
>>>>
>>>> Same here.
>>>>
>>>> I know that some people found them useful, but I don't remember why
>>>> unfortunately.
>>>
>>> The date is useful when looking at bug reports from people who might
>>> be building from development sources.
>>
>> So why not have the build procedure pick up the last commit date, if building in a Git sandbox?  That's easy enough to arrange.  Similarly, it could pick up the identifier (SHA hash) of that last commit to make it entirely unambiguous.
> 
> I wasn't saying the way we do things now is the only way, just
> explaining why the date is useful.  "git show -s --oneline @{u}" or
> similar would be good too, but let's make sure we report upstream
> commits not local ones.

If someone has local commits, it's kind of on them to know what upstream
commit those local commits are on top of.  In my general experience using
the relevant VCS identifier (git hash, svn revision, etc.) is usually the
most useful thing to have for tracking down issues.  In the case of a
regression on trunk it saves you the step of matching a date to a git hash
so you can start a bisect.

(Also, the date bump commits are indeed noisy, especially on release
branches, but there's also probably some way to filter commits shown by
git log to avoid them (e.g. omitting commits for the file in question)).

-- 
John Baldwin