Task #2998
closedMake sure all daily builds have Time at About dialog
Added by Timur Gadzo about 5 years ago. Updated about 1 year ago.
0%
Description
For us who use multiple daily builds, easiest way to see when build originated is Time at About dialog.
I see it not there at @39 Windows (that's now back after some time).
Files
| Screenshot from 2020-08-05 11-33-54.png (152 KB) Screenshot from 2020-08-05 11-33-54.png | Xisco Fauli Tarazona, 2020-08-05 11:34 |
Updated by Florian Effenberger about 5 years ago
- Assignee set to Xisco Fauli Tarazona
- Target version set to Q4/2019
Updated by Timur Gadzo about 5 years ago
It would be nice to have time also in About of bibisect repos. When I run master, how do I know when it was built?
Updated by Timur Gadzo about 5 years ago
Now when we have just 2 Win daily builds (which is enough), Win-x86_64@tb77-TDF/ builds should be named clear and similar to @39: with time in name (@39: master~2019-11-02_00.08.13_LibreOfficeDev_6.4.0.0.alpha1_Win_x86.msi).
It's important when one is using "Separate Install GUI" to see if build is updated, should it be downloaded. That's not the same as time in About dialog, this is in addition.
Now @77 is just "LibreOfficeDev_6.4.0.0.alpha0_Win_x64.msi".
Another issue with @77 is that Current doesn't point to the latest. Today 07.11. Current is from 16.10. and latest is 07.11. So just by looking at Current one might think build is not accurate.
Updated by Florian Effenberger about 5 years ago
Xisco, what are your thoughts on this? Something for ESC or team call?
Updated by Florian Effenberger almost 5 years ago
- Target version changed from Q4/2019 to Q1/2020
Xisco, any thoughts? Can/will/should we do this?
Updated by Florian Effenberger over 4 years ago
- Target version changed from Q1/2020 to Q2/2020
Gentle ping - can you give a quick feedback, Xisco?
Updated by Xisco Fauli Tarazona over 4 years ago
Time and date is displayed in dbg builds from https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF-dbg/current/ ( see screenshot )
However, the build id is not there. To me, and I think for QA/DEV people in general, it is more important to have the build id than the date and time. Some days, there are more than 50 commits submitted to master
Updated by Florian Effenberger about 4 years ago
- Status changed from New to In Progress
- Target version changed from Q2/2020 to Q4/2020
Xisco Fauli Tarazona wrote:
Time and date is displayed in dbg builds from https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF-dbg/current/ ( see screenshot )
However, the build id is not there. To me, and I think for QA/DEV people in general, it is more important to have the build id than the date and time. Some days, there are more than 50 commits submitted to master
If that is a demand by QA, can you raise that during the next ESC meeting and report back in this ticket?
Updated by Xisco Fauli Tarazona almost 4 years ago
At least the dbg builds have the date:
Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: e9e41795e6b2bf680a5f74e5684b76af00bf677b
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF-dbg, Branch:master, Time: 2021-03-02_03:34:22
Calc: threaded
Updated by Xisco Fauli Tarazona almost 4 years ago
so the solution would be to use '--with-extra-buildid' with autogen
Updated by Xisco Fauli Tarazona almost 4 years ago
Florian Effenberger wrote:
Xisco Fauli Tarazona wrote:
Time and date is displayed in dbg builds from https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF-dbg/current/ ( see screenshot )
However, the build id is not there. To me, and I think for QA/DEV people in general, it is more important to have the build id than the date and time. Some days, there are more than 50 commits submitted to masterIf that is a demand by QA, can you raise that during the next ESC meeting and report back in this ticket?
Build ID is present in recent daily builds, same as date, see my comment 9. No need to discuss anything in the ESC meeting
Updated by Beluga Beluga almost 4 years ago
Win tb77 builds don't have it and based on what Steve talked about, macOS builds don't either.
Updated by Florian Effenberger over 3 years ago
This is a rather old ticket, with a due date in Q4/2020
What's the status of this - still relevant? Who handles it, and by when?
Updated by Timur Gadzo over 3 years ago
Waiting this one and Task #3063, which was closed as a duplicate but it's not, I add a note:
seems to me that time at https://dev-builds.libreoffice.org/daily/master/current.html is time of build finish, but it should be time of build start?
For example: you see a commit from 05:00 UTC and build from 05:30, one would think that commit is in. But after download it turns out that last commit is just from 00:00, 5 hours earlier.
Updated by Xisco Fauli Tarazona over 3 years ago
Timur Gadzo wrote in #note-14:
Waiting this one and Task #3063, which was closed as a duplicate but it's not, I add a note:
seems to me that time at https://dev-builds.libreoffice.org/daily/master/current.html is time of build finish, but it should be time of build start?For example: you see a commit from 05:00 UTC and build from 05:30, one would think that commit is in. But after download it turns out that last commit is just from 00:00, 5 hours earlier.
Next to the time, you have a link to the commit, clicking on it you can see the time of the last commit included in the daily build
Updated by Xisco Fauli Tarazona over 2 years ago
- Status changed from In Progress to Rejected
After implementing https://redmine.documentfoundation.org/issues/3575, it's easy to see the time of the last commit included in the build from Bugzilla, which is more accurate than the build time.
To find more information why https://redmine.documentfoundation.org/issues/3575 solution is desirable over this ticket, please read https://bugs.documentfoundation.org/show_bug.cgi?id=148081
Rejecting
Updated by Eyal Rozenberg about 1 year ago
I would like this one to be reopened, for several reasons:
1. Copy-paste'd appearance: One often uses the text in Help|About to describe the version used. In most contexts where this text is pasted - there is no auto-linkification of the build ID, and the reader simply sees a hexadecimal string.
2. User convenience: It is not "easy" to start a browser and read a tag next to a line on the resulting web-page. That is to say, it is easy as information lookup tasks go, but as UI features go - it's hard.
3. Inaccuracy of target web page: When pressing the linkified build ID, the resulting page gives low-resolution information about the build date, e.g. "6 months ago" or "2 years ago". Yes, one can click the shortened hash and find the accurate timestamp, but that exacerbates cause (2.) further
4. Dependence on Internet connection: Sometimes, a user may wants to know when their version was built - while not connected to the Internet. That's not possible with the build ID
5. Ease of implementation: When obtaining the commit id, the build mechanism can easily also determine the commit timestamp, and plug that in as well.
So - it's a good idea to do this even if not absolutely crucial.