Thank you everyone for considering the options and rasing good points and concerns, including:
* Gaining contributors is a motivation here
* Performance might be problematic with gitlab
* FOSS options fit Inkscape values, and we should prefer to support FOSS projects, but not if it inhibits us too badly
* Other choices do exist besides just github vs. gitlab
A lot of people are voicing preference for gitlab, perhaps a majority, but we're certainly not at a full consensus. I sense that we need some actual experience under our belts, and we should plan to reassess our decision as we get into it.
Performance is, at least, something we can test. If gitlab has severe performance issues, then that should be obvious and likely measurable if we just try it.
Github certainly would give us more visibility, however there's no guarantee this would translate into more contributors. Will Entriken made a good point that being on github would enable more drive-by contributions based on general experience in various small/medium projects, however Mc makes a strong counter-argument that what we are really after are dedicated contributors, and with Inkscape already having a fairly widespread profile those folks will find us just fine regardless of the popularity of the hosting platform. Perhaps a separate outreach effort to recruit contributors after the git migration has been done would be more likely to generate good results?
So given the above, I'd like to propose a migration to githab but with several checkpoints, according to the following plan:
1. Migrate inkscape_web.
+ Keep a particular eye on performance. + Evaluate code review UX + Evaluate CI + Experiment with other features
2, Once 0.92.1 is released, we'll have a first checkpoint Checkpoint for inkscape_web.
+ Make recommendations for utilization of code review, CI, and other gitlab functionality. + Was performance a hinderance? Is the user experience acceptable? In general do the inkscape_web participants still feel as supportive of gitlab? + What concerns or issues remain, that should be watched during our initial migration? + We'll ask everyone involved in inkscape_web for a thumb's up or down. If there are thumb's down, we'll halt and re-evaluate.
3. Migrate inkscape to gitlab.
+ All bzr committers are eligible for gitlab commit access, but will need to place a request for access + At least one dry run should be done, to ensure that revision history, branches, tags, etc. are successfully converted. + Issues encountered with gitlab will be recorded, either in a dedicated bug tracker or just a simple 'complaints' web page. + Transition of wiki pages can start as desired (see separate plan proposal). + Bugs stay on LP for now
4. Outreach effort to bring in contributors
+ Leverage our release marketing procedures and contacts + Coordinate with GSoC, releases, hackfests + Ensure we have reviewers/mentors on hand
5. Following the 0.93.0 release is a second checkpoint.
+ Review the recorded issues encountered. Collect further feedback. + How has use of gitlab affected contribution levels to the Inkscape codebase? If contribution levels have not grown then we need to reassess. + All active users of the service are asked to give thumbs up/down on their experience using gitlab. If most everyone gives thumb's up, we will proceed and stick with gitlab at least until 1.0.0. Otherwise, we need to re-evaluate our plans. + Plan follow-on work to investigate/address top issues.
6. Following the 1.0.0 release, we have another reassessment of all project technologies and services. cmake, git, gitlab, C++11, gtk3, and so on. We should then plan transitions from those to whatever is next, over the course of several 1.x releases.
If you've read this far - thanks! Feedback is most appreciated.
Bryce
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"
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
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
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
I was following it closely since I have a number of code repositories there.
Someone basically hacked their system (hacked in the sense they used GitLab for hosting live streams instead of for code, not hacked as in broke into their computers)
So the admins took action and that action included deleting the whole database by accident. Then they had failure after failure getting the database backups in place.
I expect they'll be spending a few months with a sore forehead sorting the issues out. But I'm going to monitor the situation.
It was good seeing the transparency, even a livestream of the computer doing the database restore.
Best Regards, Martin Owens
On Wed, 2017-02-01 at 13:51 -0800, Krzysztof Kosiński wrote:
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-16 23:51 GMT-08:00 Bryce Harrington <bryce@...961...>:
Migrate inkscape to gitlab.
- All bzr committers are eligible for gitlab commit access, but will need to place a request for access
- At least one dry run should be done, to ensure that revision history, branches, tags, etc. are successfully converted.
- Issues encountered with gitlab will be recorded, either in a dedicated bug tracker or just a simple 'complaints' web page.
- Transition of wiki pages can start as desired (see separate plan proposal).
- Bugs stay on LP for now
Note: I have a script that fixes up several discrepant author names and e-mails in the Bazaar history. The result of this script is here: https://github.com/tweenk/inkscape/ The script has a bunch of e-mail addresses in it, so it would probably be best to share it privately.
Outreach effort to bring in contributors
- Leverage our release marketing procedures and contacts
- Coordinate with GSoC, releases, hackfests
- Ensure we have reviewers/mentors on hand
Following the 0.93.0 release is a second checkpoint.
- Review the recorded issues encountered. Collect further feedback.
- How has use of gitlab affected contribution levels to the Inkscape codebase? If contribution levels have not grown then we need to reassess.
- All active users of the service are asked to give thumbs up/down on their experience using gitlab. If most everyone gives thumb's up, we will proceed and stick with gitlab at least until 1.0.0. Otherwise, we need to re-evaluate our plans.
- Plan follow-on work to investigate/address top issues.
Following the 1.0.0 release, we have another reassessment of all project technologies and services. cmake, git, gitlab, C++11, gtk3, and so on. We should then plan transitions from those to whatever is next, over the course of several 1.x releases.
If you've read this far - thanks! Feedback is most appreciated.
Bryce
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
On Wed, 2017-02-01 at 14:28 -0800, Krzysztof Kosiński wrote:
The script has a bunch of e-mail addresses in it, so it would probably be best to share it privately.
We have a private keys repository if you'd like to use that. Or you can email the board members an email privately.
Thanks KK
Martin,
On Wed, Feb 01, 2017 at 07:12:57PM -0500, Martin Owens wrote:
On Wed, 2017-02-01 at 14:28 -0800, Krzysztof Kosiński wrote:
The script has a bunch of e-mail addresses in it, so it would probably be best to share it privately.
We have a private keys repository if you'd like to use that. Or you can email the board members an email privately.
+1
Also, as a side remark, I've been tinkering with git-crypt (in relation to needs of the X.org project). If we have data like that which needs to be shared but kept private that may be another option to consider, once we convert to git.
Bryce
Am Mittwoch, 1. Februar 2017, 23:50:14 CET schrieb Bryce Harrington:
On Wed, Feb 01, 2017 at 07:12:57PM -0500, Martin Owens wrote:
On Wed, 2017-02-01 at 14:28 -0800, Krzysztof Kosiński wrote:
The script has a bunch of e-mail addresses in it, so it would probably be best to share it privately.
We have a private keys repository if you'd like to use that. Or you can email the board members an email privately.
+1
Also, as a side remark, I've been tinkering with git-crypt (in relation to needs of the X.org project). If we have data like that which needs to be shared but kept private that may be another option to consider, once we convert to git.
You are aware that the commits themselves are public and that all those email addresses that are used so far are therefore public, too? Just saying.
Apart from that, I still don't understand why anyone would change the mail addresses from old commits. It's part of the history.
Bryce
Tobias
participants (5)
-
Bryce Harrington -
Krzysztof Kosiński -
Marc Jeanmougin -
Martin Owens -
Tobias Ellinghaus