On Wed, Jan 18, 2017 at 05:42:19PM +0100, Marc Jeanmougin wrote:
On 01/17/2017 08:51 AM, Bryce Harrington wrote:
Migrate inkscape to gitlab.
[...]
Just as a remark, there will be bugs linked to the transition from bzr to git itself: some build parts are linked to "bzr revno" for instance, so some cmake code will have to be fixed just after the code migration, and we'll also have to decide what to put in the about screen instead of the revno. Probably the best option might be the git commit hash and/or datetime if it's easily extractable from git.
"Inkscape 0.92+devel (2017-01-18 17:38:31)" might be more readable than "Inkscape 0.92+devel f0e47570d3776c373066cc61595b1ba14fa9b366"
Another option might be:
"Inkscape 0.92+devel (2017-01-18 f0e47570)"
The first 8 chars of the SHA are usually always adequate to uniquely identify the commit, and will be more manageable than the full SHA in this case.
I do think showing the (partial) SHA is what we want, as the purpose of showing the revno is to assist in identifying where a regression occurred, and since a number of git commands work with SHAs so listing it here will eliminate an extra step that bug triagers would need to do anyway.
Showing the date is handy too since it'll communicate to users the relative age of the build (which SHA's don't communicate in the way that bzr's revno's do.) We have a few different options for what date to show: The commit date of the patch, the author date of the patch, and the build date. Guessing the commit date would be most logical here but I'm not actually sure.
Mc, could you start collecting issues like these? Maybe file bugs in LP and tag them 'gitlab-migration' or something so we can find them. I think they should be pretty straightforward to rig up in git, and I'll make sure we get them addressed as we migrate.
Bryce