Regarding gitlab, there's a developing story today:
https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/
Basically, they did not bother to validate restoring from backups, which does not inspire confidence...
2017-01-18 10:08 GMT-08:00 Tobias Ellinghaus <houz@...173...>:
Am Mittwoch, 18. Januar 2017, 09:35:31 CET schrieb Bryce Harrington:
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.
Ack. A nice way of getting such a version string is
git describe --tags --dirty
which will tell the last tag, whether there are changes to the checkout (the --dirty), the short hash of the last commit and also the number of commits since the tag. For darktable that looks like this:
release-2.3.0-266-gfefb0204e-dirty
It's not too hard to clean up the tag name (remove "release-") and add the commit date.
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.
I'd also use the commit date. Author date can be arbitrarily far in the past.
[...]
Bryce
Tobias
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel