Am 01.03.2017 um 22:19 schrieb Bryce Harrington:
On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
Thanks everyone who provided feedback on the plan to migrate to gitlab. I've updated the plan to incorporate all the feedback (see attached diff for what changed).
Thank you, Bryce (and sorry for delay - mail server issues...)
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.
- It just worked as expected. The code review pages are very similar to github's. To see the code that has changed (in a merge request) you need to click on a tab at the bottom, and I didn't find it right away, but it's just a different interface that one would need to get used to.
+ Was performance a hinderance?
- No. I know they currently have (or had? development is so fast) an issue with issue threads that are too long slowing down the browser (and were working on it), but ours don't pose a problem. The site loads fast enough, and the command line interactions didn't seem to take longer or shorter than those with github or launchpad.
Is the user experience acceptable?
- For me, it's fine - after Martin added a webhook that sends an email with a diff on push events. I felt blind without that (but it seems to be the norm, it's the same on github).
Their permission settings are very fine-grained. That's nice. Issues work as expected, labels can replace the functionality of the missing sorting options. Their issue boards (where one can create work lists from labels) seem to be a nice addition. Comparison between branches is easily accessible. Branches can be locked, and groups and single people can be allowed access. There is no such concept as a team, only projects, and overarching groups with multiple projects inside, and people with different permissions on them. The online editor worked as expected.
Martin used the Wiki for drafting a blueprint.
Accessing the code seems to be easy enough for new contributors, inkscape-web already has a couple of forks, and we've had the same number of regulars as usual (which is 3 - Sylvain joined us there, too.).
For setting up the 'view' permissions (yes, there are separate permissions for just looking at different functionality), it was good that su_v was already a long-time gitlab user and was able to help us there. The phrasing of some of the options was a bit misleading. The settings interface is currently being reworked, though. I assume that setup is a one-time thing, so not a very relevant problem, once you know what it means.
Setting up the translations repo for inkscape-web was straightforward, and after permission issues were cleared up (make sure to check for branch protections), as Martin already said, I even played with their CI. With my level of knowledge and their documentation, it was easy enough to set up a script that is run on each commit and checks if po files compile.
New releases are frequent events (see blog archive for overview: https://about.gitlab.com/blog/archives.html). Usually, there was no noticable downtime. Gitlab development appears to be extremely active.
We didn't use milestones, release tags, any of the issue templates, push rules, rules for merging (like: how many approvals are needed), hosting of own container images at gitlab, and probably a lot more, but there exists an unbelievable amount of possibilities.
In general do the inkscape_web participants still feel as supportive of gitlab?
- I do, yes.
+ Retrospective on the 2/1/2017 hack + loss of backups - https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/ - Issue itself is bad. Transparency they showed is good. - It's been a month, have they adequately sorted things out?
- It wasn't exactly a hack, more human error, plus nobody checking if backups worked. Transparency was amazing, and still is (they're now providing records of their team meetings online). Postmortem is here: https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january...
9 of 14 issues that were connected to the data loss (linked from the postmortem) are closed now. I can't tell how important the respective issues are. Some of the open ones didn't get an update within the last two or three weeks, but work on all of them has been started.
(If I were a twitter user, I'd just have asked them for a general overview of current backup state, but I'm not, and the issues themselves are an unsuitable place for this.)
+ Is gitlab's CI build system up to the task for Inkscape? What provisions will we need to make (e.g. supplying our own build hosts)
- It seems it's possible to upload one's own docker container images, but not tested.
+ 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.
- Thumbs up from me. No issues with inkscape-web or inkscape-web-i18n on gitlab.
Maren
Migrate inkscape to gitlab.
- All bzr committers are eligible for gitlab commit access, but will need to place a request for access
- tweenk has a script to fix up discrepant author names and e-mails. Can't be shared publically since has personal info (but could be passed to a board member via pgp encrypt).
- At least one dry run should be done, to ensure that revision history, branches, tags, etc. are successfully converted.
- Functionality that uses 'bzr revno' (like the about screen) will need modified to use git.
- Formatting for about screen should be something resembling: "Inkscape 0.92+devel (2017-01-18 f0e47570)"
- git describe --tags --dirty 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. It's not too hard to clean up the tag name (remove "release-") and add the commit date.
- Use the commit date rather than the author date
- Issues encountered with gitlab will be recorded in our bug tracker with the 'gitlab-migration' tag.
- Transition of wiki pages can start as desired (see separate plan proposal).
- Bugs stay on LP for now
Outreach effort to bring in contributors
- Assemble an outreach/advocacy team
- 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.
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
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