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). With 0.92.1 now out the door, this seems like an opportune time to proceed with Step 2 of the migration, if no one objects?
So, Martin, Maren, jazzynico, and others who have been maintaining inkscape-related products on gitlab, would you mind sharing your experiences with gitlab, and whether you recommend for or against migrating inkscape itself at this time?
Bryce
------------------------------------------------------------------------
[DONE] 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? + 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? + 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) + 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 + 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
4. 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
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.