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.
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.
See also: https://redmine.documentfoundation.org/issues/3575
(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.
(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).
(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.
(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.
(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 ;)
Xisco, please comment if this should be closed as Redmine already exists (URL).
Not a topic for UX but QA. Personally, I can follow Mike's arguments although the hash is meaningless to me.
(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
Note that the Redmine bug has been closed.