Bug 148081 - Copyable version info (for non-releases?) should include build date
Summary: Copyable version info (for non-releases?) should include build date
Status: RESOLVED MOVED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: https://redmine.documentfoundation.or...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-19 11:00 UTC by Eyal Rozenberg
Modified: 2023-11-24 23:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-03-19 11:00:10 UTC
The 'About' dialog in most (all?) LO apps includes build information one can copy to report bugs. The fields are:

Version
Build ID
CPU threads
OS
Linux 5.10
UI render
VCL
Locale
Calc threading state

This is missing the build _date_. The build ID is a hash, and does not explicitly include the build date; and the version, while indirectly suggesting in what range of dates the build occurred, is insufficient. It would be useful for triage purposes, and even for deciding when to switch to a newer build, to be able to tell whether one's own build is newer than some other reported build.

So, I suggest a build date field be added.
Comment 1 Mike Kaganski 2022-03-19 11:57:10 UTC
I disagree that build date is a useful information. While dailies are *usually* built at the date that reflects the current head, it is not so e.g. for bibisect builds, and generally is not required to be synchronized.

I suggest instead to add a linkifier to Bugzilla, so that when a build hash appears, it is represented as a link, and would simplify checking the date, along with other relevant info. It would also simplify providing the links when one bibisects, since today one needs to copy-paste the source hash, *and* also the link, to allow others to navigate to the commit easily.
Comment 2 Mike Kaganski 2022-03-19 12:17:57 UTC
See also: https://redmine.documentfoundation.org/issues/3575
Comment 3 Eyal Rozenberg 2022-03-19 14:18:28 UTC
(In reply to Mike Kaganski from comment #1)
> I disagree that build date is a useful information. While dailies are
> *usually* built at the date that reflects the current head, it is not so
> e.g. for bibisect builds, and generally is not required to be synchronized.

Ok, then, make it the date of the built branch then.

The point is that when I look at my build info, and some build info pasted into a bug page here, I want to know which one is earlier than the other and by how much; and I would also like to know how old each of them are individually.


> I suggest instead to add a linkifier to Bugzilla, so that when a build hash
> appears, it is represented as a link, and would simplify checking the date,
> along with other relevant info. It would also simplify providing the links
> when one bibisects, since today one needs to copy-paste the source hash,
> *and* also the link, to allow others to navigate to the commit easily.

But the linkifier doesn't work when you get email. Nor does it work in your own LO installation. So, while it may be a good idea, I still want the build date / built branch HEAD date.
Comment 4 Mike Kaganski 2022-03-19 15:09:57 UTC
(In reply to Eyal Rozenberg from comment #3)
> But the linkifier doesn't work when you get email.

Why? Why shouldn't the email include the link that Bugzilla generates, when it sends the email?

> Nor does it work in your own LO installation.

Why? You have *link* in the build. At least with TDF builds and personal builds.

And anyway, "which one is earlier than the other and by how much" makes absolutely no sense, since they may be from different branches, and what's important is if they include something in their history or not - which is only possible to see if you use git tools, available when you follow the links (you can see the commit history there).
Comment 5 Eyal Rozenberg 2022-03-19 15:26:32 UTC
(In reply to Mike Kaganski from comment #4)
> Why? Why shouldn't the email include the link that Bugzilla generates, when
> it sends the email?

Well, that's not how bugzilla email messgaes usually work, but if you can get it to happen, then ok.


> Why? You have *link* in the build. At least with TDF builds and personal
> builds.

I meant that if you press the copy button you don't get the date. But it's true that you can click the link in the dialog and check. It's just an inconvenience (plus, the commit "dates" are listed in relative terms). If I can get the calc threading flag, I don't see why I can't have the head commit date.

> since they may be from different branches

But when that's the case, isn't that indicated in the version string?

> and what's important is if they include something in their history or not - which is only possible to see if you use git tools, available when you follow the links (you can see the commit history there).

That's more important for developers, but less for QA monkeys like us, who, if we have a non-release build at all, it's a daily.
Comment 6 Mike Kaganski 2022-03-19 15:53:26 UTC
(In reply to Eyal Rozenberg from comment #5)
> That's more important for developers, but less for QA

The bottom line of my argument is: it is not good to add something to the information, that is potentially confusing, since it is part of multi-dimensional state, and would be only helpful in some specific narrow ramifications, but otherwise would confuse unaware people, who would simply assume that "later means more complete" (or "has everything the older has, plus extra"), which is not generally correct.

I would strongly suggest to not add that, but instead make it easier to navigate to the related commit web page, which provides both date and lots more information.
Comment 7 Mike Kaganski 2022-03-19 15:59:04 UTC
(In reply to Mike Kaganski from comment #6)

Note that I mean that exactly about QA; I see the "(for non-releases?)" part in the title, and argue with that in mind. QA people have different level of knowledge about the release process; and people who test dailies are not limited to those who are seasoned contributors to the Bugzilla ;)
Comment 8 Timur 2022-03-21 09:02:19 UTC
Xisco, please comment if this should be closed as Redmine already exists (URL).
Comment 9 Heiko Tietze 2022-03-21 09:48:08 UTC
Not a topic for UX but QA. Personally, I can follow Mike's arguments although the hash is meaningless to me.
Comment 10 Xisco Faulí 2022-03-23 11:17:26 UTC
(In reply to Mike Kaganski from comment #2)
> See also: https://redmine.documentfoundation.org/issues/3575

Yep, I think it's a great idea. I'll try to implement it.
Closing as RESOLVED MOVED
Comment 11 Eyal Rozenberg 2023-11-24 23:00:08 UTC
Note that the Redmine bug has been closed.