Gitlab Evaluation & Migration
Hi all, Over the past few months a small group of KDE projects have been evaluating Gitlab as a replacement for Phabricator, and we’ve now reached the point where we’re ready to have a community wide discussion regarding whether we’d like to migrate to Gitlab. We'd like to start this by thanking those projects that have assisted in evaluating Gitlab for KDE, at list of which can be found at https://invent.kde.org/kde/ This evaluation process was started in response to feedback Sysadmin received in the BoF session in Akademy last year regarding issues developers we're having with Phabricator. These included the ability to see the submitters details (name and email address), ability to do multi-commit reviews and to merge changes conveniently from the web amongst other things. Based on the feedback we’ve received to date regarding the Gitlab evaluation, the consensus seems to be that a migration would be beneficial and helpful to us in the long term. Among the benefits identified thus far are: 1) Provision of full featured task management and code review functionality to scratch (personal) repositories, which will ease the transition to playground and first release. 2) Ability to handle native Git commits as part of the code review process and merge commits from the web interface rather than having to take additional steps to integrate a change. 3) Easier and more logical grouping of projects, including being able to view the tasks and repositories related to a specific project more intuitively Further notes on the evaluation can be found at https://notes.kde.org/p/gitlab-evaluation-notes In regards to Phabricator it should be noted that upstream does not currently have plans to work on features which would resolve the issues we've encountered, and their responsiveness to inquiries from us has decreased since we migrated to it several years ago. Gitlab on the other hand has a thriving community which openly accepts patches and have been very helpful in assisting us with the evaluation process (including solving problems we've found). In addition to sysadmins and some of projects maintainers, KDE e.V. board, and onboarding goal team has been involved in Gitlab evaluation process as well, and they've made the following comments: Neofytos Kolokotronis of the Onboarding goal team: We believe this switch will be a great step forward for the Onboarding goal as well. The workflow, features and general behavior of Gitlab should be much more familiar to developers and non-coders interested to contribute to KDE, thus lowering the entry barrier. Further, people coming from FOSS projects already on Github or Gitlab should find it very straightforward to start contributing to KDE right away. One area that is not to be ignored is that Gitlab has some great and up to date documentation. Eike Hein on behalf of the KDE e.V. board of directors: After sysadmin gave us a situation report on our code hosting and review infrastructure last year, we were initially involved with building a relationship with GitLab upstream and setting up a call schedule. We then turned the evaluation over to the sysadmin and onboarding teams and received continual updates on its progress. We're impressed by and thankful for the work done by everyone involved in the intervening months, and stand by to help implement a community decision based on what was collected. Based on all of the above we'd like to propose migrating towards Gitlab. Comments? Thanks, Ben Cooksley KDE Sysadmin
Re: Gitlab Evaluation & Migration
On Sat, Feb 23, 2019 at 1:44 PM Ben Cooksley wrote: > Hi all, > > Over the past few months a small group of KDE projects have been > evaluating Gitlab as a replacement for Phabricator, and we’ve now > reached the point where we’re ready to have a community wide > discussion regarding whether we’d like to migrate to Gitlab. We'd like > to start this by thanking those projects that have assisted in > evaluating Gitlab for KDE, at list of which can be found at > https://invent.kde.org/kde/ > > This evaluation process was started in response to feedback Sysadmin > received in the BoF session in Akademy last year regarding issues > developers we're having with Phabricator. These included the ability > to see the submitters details (name and email address), ability to do > multi-commit reviews and to merge changes conveniently from the web > amongst other things. > > Based on the feedback we’ve received to date regarding the Gitlab > evaluation, the consensus seems to be that a migration would be > beneficial and helpful to us in the long term. > > Among the benefits identified thus far are: > 1) Provision of full featured task management and code review > functionality to scratch (personal) repositories, which will ease the > transition to playground and first release. > 2) Ability to handle native Git commits as part of the code review > process and merge commits from the web interface rather than having to > take additional steps to integrate a change. > 3) Easier and more logical grouping of projects, including being able > to view the tasks and repositories related to a specific project more > intuitively > > Further notes on the evaluation can be found at > https://notes.kde.org/p/gitlab-evaluation-notes > > In regards to Phabricator it should be noted that upstream does not > currently have plans to work on features which would resolve the > issues we've encountered, and their responsiveness to inquiries from > us has decreased since we migrated to it several years ago. My own experience agrees with this statement. I've got an impression that Phabricator devs completely not interested in bug reports coming from users with a pact (a term for paid support used by Phacility). So, I'm all for moving from Phabricator and that PHP-based CLI. Gitlab on > the other hand has a thriving community which openly accepts patches > and have been very helpful in assisting us with the evaluation process > (including solving problems we've found). > > In addition to sysadmins and some of projects maintainers, KDE e.V. > board, and onboarding goal team has been involved in Gitlab evaluation > process as well, and they've made the following comments: > > Neofytos Kolokotronis of the Onboarding goal team: > We believe this switch will be a great step forward for the Onboarding > goal as well. The workflow, features and general behavior of Gitlab > should be much more familiar to developers and non-coders interested > to contribute to KDE, thus lowering the entry barrier. Further, > people coming from FOSS projects already on Github or Gitlab should > find it very straightforward to start contributing to KDE right away. > One area that is not to be ignored is that Gitlab has some great and > up to date documentation. > > Eike Hein on behalf of the KDE e.V. board of directors: > After sysadmin gave us a situation report on our code hosting and > review infrastructure last year, we were initially involved with > building a relationship with GitLab upstream and setting up a call > schedule. We then turned the evaluation over to the sysadmin and > onboarding teams and received continual updates on its progress. We're > impressed by and thankful for the work done by everyone involved in > the intervening months, and stand by to help implement a community > decision based on what was collected. > > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? > > Thanks, > Ben Cooksley > KDE Sysadmin >
Re: Gitlab Evaluation & Migration
On zaterdag 23 februari 2019 10:44:11 CET Ben Cooksley wrote: > https://notes.kde.org/p/gitlab-evaluation-notes A few notes on my side: * Krita has been using the mockup functionality extensively. We would miss that functionality, as we actually do UX design for our new features. * It's ages since I used gitlab myself (2015, I think), but I've always found the ease with which a patch can be submitted for a repo a good thing in phabricator. * Is there anything we can have that can replace tasks and workboards? We usually have some very long-running tasks that get a lot of sub-tasks and that basically document our development process. One thing I've learned with Phabricator is that project planning and issue tracking have nothing to do with each other. -- https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Gitlab Evaluation & Migration
В Сб, 23 фев. 2019 в 2:08 ПП (PM), Boudewijn Rempt написал: On zaterdag 23 februari 2019 10:44:11 CET Ben Cooksley wrote: https://notes.kde.org/p/gitlab-evaluation-notes A few notes on my side: * Krita has been using the mockup functionality extensively. We would miss that functionality, as we actually do UX design for our new features. * It's ages since I used gitlab myself (2015, I think), but I've always found the ease with which a patch can be submitted for a repo a good thing in phabricator. As someone who uses gitlab on a dayjob I can tell it's pretty easy too. With disregard to server interface you do `git push my-fork HEAD`, right? Now, when you push to gitlab server, you get in the git output a link that refers to creating a merge request to upstream. You just click it, and then in a browser press "Ok". * Is there anything we can have that can replace tasks and workboards? We usually have some very long-running tasks that get a lot of sub-tasks and that basically document our development process. One thing I've learned with Phabricator is that project planning and issue tracking have nothing to do with each other. -- https://www.krita.org
Re: Gitlab Evaluation & Migration
Concerning Latte Dock, there is no objection in migrating to Gitlab. I like it a lot as it reminds me GitHub and it will probably welcome also new contributors (not only developers but also enthusiast users). regards, michail Στις Σάβ, 23 Φεβ 2019 στις 11:44 π.μ., ο/η Ben Cooksley έγραψε: > Hi all, > > Over the past few months a small group of KDE projects have been > evaluating Gitlab as a replacement for Phabricator, and we’ve now > reached the point where we’re ready to have a community wide > discussion regarding whether we’d like to migrate to Gitlab. We'd like > to start this by thanking those projects that have assisted in > evaluating Gitlab for KDE, at list of which can be found at > https://invent.kde.org/kde/ > > This evaluation process was started in response to feedback Sysadmin > received in the BoF session in Akademy last year regarding issues > developers we're having with Phabricator. These included the ability > to see the submitters details (name and email address), ability to do > multi-commit reviews and to merge changes conveniently from the web > amongst other things. > > Based on the feedback we’ve received to date regarding the Gitlab > evaluation, the consensus seems to be that a migration would be > beneficial and helpful to us in the long term. > > Among the benefits identified thus far are: > 1) Provision of full featured task management and code review > functionality to scratch (personal) repositories, which will ease the > transition to playground and first release. > 2) Ability to handle native Git commits as part of the code review > process and merge commits from the web interface rather than having to > take additional steps to integrate a change. > 3) Easier and more logical grouping of projects, including being able > to view the tasks and repositories related to a specific project more > intuitively > > Further notes on the evaluation can be found at > https://notes.kde.org/p/gitlab-evaluation-notes > > In regards to Phabricator it should be noted that upstream does not > currently have plans to work on features which would resolve the > issues we've encountered, and their responsiveness to inquiries from > us has decreased since we migrated to it several years ago. Gitlab on > the other hand has a thriving community which openly accepts patches > and have been very helpful in assisting us with the evaluation process > (including solving problems we've found). > > In addition to sysadmins and some of projects maintainers, KDE e.V. > board, and onboarding goal team has been involved in Gitlab evaluation > process as well, and they've made the following comments: > > Neofytos Kolokotronis of the Onboarding goal team: > We believe this switch will be a great step forward for the Onboarding > goal as well. The workflow, features and general behavior of Gitlab > should be much more familiar to developers and non-coders interested > to contribute to KDE, thus lowering the entry barrier. Further, > people coming from FOSS projects already on Github or Gitlab should > find it very straightforward to start contributing to KDE right away. > One area that is not to be ignored is that Gitlab has some great and > up to date documentation. > > Eike Hein on behalf of the KDE e.V. board of directors: > After sysadmin gave us a situation report on our code hosting and > review infrastructure last year, we were initially involved with > building a relationship with GitLab upstream and setting up a call > schedule. We then turned the evaluation over to the sysadmin and > onboarding teams and received continual updates on its progress. We're > impressed by and thankful for the work done by everyone involved in > the intervening months, and stand by to help implement a community > decision based on what was collected. > > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? > > Thanks, > Ben Cooksley > KDE Sysadmin >
Re: Gitlab Evaluation & Migration
On zaterdag 23 februari 2019 14:49:25 CET Konstantin Kharlamov wrote: > As someone who uses gitlab on a dayjob I can tell it's pretty easy too. > With disregard to server interface you do `git push my-fork HEAD`, > right? Now, when you push to gitlab server, you get in the git output a > link that refers to creating a merge request to upstream. You just > click it, and then in a browser press "Ok". No, you misunderstand me. In the first place, we've got a lot of people in our community who wouldn't understand a single word of that paragraph. What they understand is * clone the repo * hack * type 'git diff > mydiff.diff' * upload the diff for review * add a bit of text explaining the change * wait for me or dmitry to look at their patches They don't have push access to kde's git server at all, so I guess 'git push my-fork HEAD' won't work in any case. -- https://www.valdyas.org | https://www.krita.org
Re: Gitlab Evaluation & Migration
Hi, On 23.02.2019 16:56, Boudewijn Rempt wrote: On zaterdag 23 februari 2019 14:49:25 CET Konstantin Kharlamov wrote: No, you misunderstand me. In the first place, we've got a lot of people in our community who wouldn't understand a single word of that paragraph. What they understand is "A lot" is probably a bit exaggerated, e.g. I don't really know where to upload patches to Phabricator or create a pull request there, but do understand how GitLab works. So I guess we have many different people in the community and many of them can get used to change. * clone the repo * hack * git commit * git push awesome-feature-branch * click on the link in the output * add a bit of text explaining the change * wait for me or dmitry to look at their patches One more step for the first creation of a merge request. Not that much different. They don't have push access to kde's git server at all, so I guess 'git push my-fork HEAD' won't work in any case. I guess this needs to change (with more fine grained permissions), the whole Merge Request System is based on merging other branches to Master. Afaik uploading just a patch doesn't work in GitLab. Stefan
Re: Gitlab Evaluation & Migration
Hi Ben et. al., What are our plans regarding integrating with GitLab CI? I see that we have the YAML files in some of the repos already, but do we plan to replace Jenkins in the long run? Sincerely, Boudhayan Gupta On Sat, 23 Feb 2019 at 11:04, Gleb Popov <6year...@gmail.com> wrote: > > > On Sat, Feb 23, 2019 at 1:44 PM Ben Cooksley wrote: > >> Hi all, >> >> Over the past few months a small group of KDE projects have been >> evaluating Gitlab as a replacement for Phabricator, and we’ve now >> reached the point where we’re ready to have a community wide >> discussion regarding whether we’d like to migrate to Gitlab. We'd like >> to start this by thanking those projects that have assisted in >> evaluating Gitlab for KDE, at list of which can be found at >> https://invent.kde.org/kde/ >> >> This evaluation process was started in response to feedback Sysadmin >> received in the BoF session in Akademy last year regarding issues >> developers we're having with Phabricator. These included the ability >> to see the submitters details (name and email address), ability to do >> multi-commit reviews and to merge changes conveniently from the web >> amongst other things. >> >> Based on the feedback we’ve received to date regarding the Gitlab >> evaluation, the consensus seems to be that a migration would be >> beneficial and helpful to us in the long term. >> >> Among the benefits identified thus far are: >> 1) Provision of full featured task management and code review >> functionality to scratch (personal) repositories, which will ease the >> transition to playground and first release. >> 2) Ability to handle native Git commits as part of the code review >> process and merge commits from the web interface rather than having to >> take additional steps to integrate a change. >> 3) Easier and more logical grouping of projects, including being able >> to view the tasks and repositories related to a specific project more >> intuitively >> >> Further notes on the evaluation can be found at >> https://notes.kde.org/p/gitlab-evaluation-notes >> >> In regards to Phabricator it should be noted that upstream does not >> currently have plans to work on features which would resolve the >> issues we've encountered, and their responsiveness to inquiries from >> us has decreased since we migrated to it several years ago. > > > My own experience agrees with this statement. I've got an impression that > Phabricator devs completely not interested in bug reports coming from users > with a pact (a term for paid support used by Phacility). > > So, I'm all for moving from Phabricator and that PHP-based CLI. > > Gitlab on >> the other hand has a thriving community which openly accepts patches >> and have been very helpful in assisting us with the evaluation process >> (including solving problems we've found). >> >> In addition to sysadmins and some of projects maintainers, KDE e.V. >> board, and onboarding goal team has been involved in Gitlab evaluation >> process as well, and they've made the following comments: >> >> Neofytos Kolokotronis of the Onboarding goal team: >> We believe this switch will be a great step forward for the Onboarding >> goal as well. The workflow, features and general behavior of Gitlab >> should be much more familiar to developers and non-coders interested >> to contribute to KDE, thus lowering the entry barrier. Further, >> people coming from FOSS projects already on Github or Gitlab should >> find it very straightforward to start contributing to KDE right away. >> One area that is not to be ignored is that Gitlab has some great and >> up to date documentation. >> >> Eike Hein on behalf of the KDE e.V. board of directors: >> After sysadmin gave us a situation report on our code hosting and >> review infrastructure last year, we were initially involved with >> building a relationship with GitLab upstream and setting up a call >> schedule. We then turned the evaluation over to the sysadmin and >> onboarding teams and received continual updates on its progress. We're >> impressed by and thankful for the work done by everyone involved in >> the intervening months, and stand by to help implement a community >> decision based on what was collected. >> >> Based on all of the above we'd like to propose migrating towards >> Gitlab. Comments? >> >> Thanks, >> Ben Cooksley >> KDE Sysadmin >> >
Re: Gitlab Evaluation & Migration
On Sun, Feb 24, 2019 at 4:56 AM Boudewijn Rempt wrote: > > On zaterdag 23 februari 2019 14:49:25 CET Konstantin Kharlamov wrote: > > > As someone who uses gitlab on a dayjob I can tell it's pretty easy too. > > With disregard to server interface you do `git push my-fork HEAD`, > > right? Now, when you push to gitlab server, you get in the git output a > > link that refers to creating a merge request to upstream. You just > > click it, and then in a browser press "Ok". > > No, you misunderstand me. In the first place, we've got a lot of people in > our community who wouldn't understand a single word of that paragraph. What > they understand is > > * clone the repo > * hack > * type 'git diff > mydiff.diff' > * upload the diff for review > * add a bit of text explaining the change > * wait for me or dmitry to look at their patches > > They don't have push access to kde's git server at all, so I guess 'git push > my-fork HEAD' won't work in any case. The workflow in this case will be slightly different, but should be a very familiar workflow for those coming from a Github world. 1) Login to invent.kde.org, fork the repository there into your personal namespace 2) Clone the forked repository to your local system 3) Hack 4) Commit and push your changes to the forked repository 5) Follow the link in the push to create the merge request, adding all the necessary commentary around it 6) Wait for review Once you're happy with it you can integrate it by merging it from the web interface (so no need to download and apply the patch locally) Of course you'll still have the option of fetching their changes and reviewing them on your local machine should you wish. More documentation on merge requests is available at https://invent.kde.org/help/user/project/merge_requests/index.md > > -- > https://www.valdyas.org | https://www.krita.org > > Cheers, Ben
Re: Gitlab Evaluation & Migration
On zaterdag 23 februari 2019 18:58:46 CET ste...@derkits.at wrote: > "A lot" is probably a bit exaggerated, e.g. I don't really know where to > upload patches to Phabricator or create a pull request there, but do > understand how GitLab works. I was talking about the Krita community, which uses Phabricator extensively in this way. I don't think you're familiar enough with the Krita community to make this comment. Also, not knowing some thing (how to find the Code Review link in the https://phabricator.kde.org/ homepage) while being familiar with another workflow doesn't mean that the first thing is hard, and the second one not. > So I guess we have many different people in the community and many of > them can get used to change. Everyone can get used to change; as long as the thing remains possible. > > * clone the repo > > * hack > > * git commit > * git push awesome-feature-branch So, basically, what you're saying is that unless a person has push rights, they cannot collaborate? That's worse than I thought. > * click on the link in the output > > > > * add a bit of text explaining the change > > * wait for me or dmitry to look at their patches > > One more step for the first creation of a merge request. Not that much > different. > > > They don't have push access to kde's git server at all, so I guess > > 'git push my-fork HEAD' won't work in any case. > > I guess this needs to change (with more fine grained permissions), the > whole Merge Request System is based on merging other branches to Master. > Afaik uploading just a patch doesn't work in GitLab. Well, that's too bad. Unless someone can explain to me how people can submit patches for review without having push rights, a migration seems impossible. It's already hard for some people to understand they need to create a KDE identity, but once they've got that, they should be able to offer patches for review. -- https://www.valdyas.org | https://www.krita.org
Re: Gitlab Evaluation & Migration
On Sun, Feb 24, 2019 at 7:28 AM Boudhayan Gupta wrote: > > Hi Ben et. al., > > What are our plans regarding integrating with GitLab CI? I see that we have > the YAML files in some of the repos already, but do we plan to replace > Jenkins in the long run? We've been experimenting with it, mostly at this time as a way of providing CI on merge requests. Our main issue at this stage is determining a way of deploying it in a way that is maintainable (at the moment with Jenkins all builds are conducted from a small set of central templates which makes implementing KDE wide changes trivial, however Gitlab requires per-repository .gitlab-ci.yaml files) Once we've sorted that, it will definitely be brought online at the very least to provide CI on merge requests and may quite possibly replace build.kde.org as well. Due to complexities and other security concerns changes to the Binary Factory are not under consideration at this time. > > Sincerely, > Boudhayan Gupta > Cheers, Ben > > On Sat, 23 Feb 2019 at 11:04, Gleb Popov <6year...@gmail.com> wrote: >> >> >> >> On Sat, Feb 23, 2019 at 1:44 PM Ben Cooksley wrote: >>> >>> Hi all, >>> >>> Over the past few months a small group of KDE projects have been >>> evaluating Gitlab as a replacement for Phabricator, and we’ve now >>> reached the point where we’re ready to have a community wide >>> discussion regarding whether we’d like to migrate to Gitlab. We'd like >>> to start this by thanking those projects that have assisted in >>> evaluating Gitlab for KDE, at list of which can be found at >>> https://invent.kde.org/kde/ >>> >>> This evaluation process was started in response to feedback Sysadmin >>> received in the BoF session in Akademy last year regarding issues >>> developers we're having with Phabricator. These included the ability >>> to see the submitters details (name and email address), ability to do >>> multi-commit reviews and to merge changes conveniently from the web >>> amongst other things. >>> >>> Based on the feedback we’ve received to date regarding the Gitlab >>> evaluation, the consensus seems to be that a migration would be >>> beneficial and helpful to us in the long term. >>> >>> Among the benefits identified thus far are: >>> 1) Provision of full featured task management and code review >>> functionality to scratch (personal) repositories, which will ease the >>> transition to playground and first release. >>> 2) Ability to handle native Git commits as part of the code review >>> process and merge commits from the web interface rather than having to >>> take additional steps to integrate a change. >>> 3) Easier and more logical grouping of projects, including being able >>> to view the tasks and repositories related to a specific project more >>> intuitively >>> >>> Further notes on the evaluation can be found at >>> https://notes.kde.org/p/gitlab-evaluation-notes >>> >>> In regards to Phabricator it should be noted that upstream does not >>> currently have plans to work on features which would resolve the >>> issues we've encountered, and their responsiveness to inquiries from >>> us has decreased since we migrated to it several years ago. >> >> >> My own experience agrees with this statement. I've got an impression that >> Phabricator devs completely not interested in bug reports coming from users >> with a pact (a term for paid support used by Phacility). >> >> So, I'm all for moving from Phabricator and that PHP-based CLI. >> >>> Gitlab on >>> the other hand has a thriving community which openly accepts patches >>> and have been very helpful in assisting us with the evaluation process >>> (including solving problems we've found). >>> >>> In addition to sysadmins and some of projects maintainers, KDE e.V. >>> board, and onboarding goal team has been involved in Gitlab evaluation >>> process as well, and they've made the following comments: >>> >>> Neofytos Kolokotronis of the Onboarding goal team: >>> We believe this switch will be a great step forward for the Onboarding >>> goal as well. The workflow, features and general behavior of Gitlab >>> should be much more familiar to developers and non-coders interested >>> to contribute to KDE, thus lowering the entry barrier. Further, >>> people coming from FOSS projects already on Github or Gitlab should >>> find it very straightforward to start contributing to KDE right away. >>> One area that is not to be ignored is that Gitlab has some great and >>> up to date documentation. >>> >>> Eike Hein on behalf of the KDE e.V. board of directors: >>> After sysadmin gave us a situation report on our code hosting and >>> review infrastructure last year, we were initially involved with >>> building a relationship with GitLab upstream and setting up a call >>> schedule. We then turned the evaluation over to the sysadmin and >>> onboarding teams and received continual updates on its progress. We're >>> impressed by and thankful for the work done by everyone involved in >>> the intervening months,
Re: Gitlab Evaluation & Migration
On Sun, Feb 24, 2019 at 8:06 AM Boudewijn Rempt wrote: > > On zaterdag 23 februari 2019 18:58:46 CET ste...@derkits.at wrote: > > > "A lot" is probably a bit exaggerated, e.g. I don't really know where to > > upload patches to Phabricator or create a pull request there, but do > > understand how GitLab works. > > I was talking about the Krita community, which uses Phabricator extensively > in this way. I don't think you're familiar enough with the Krita community to > make this comment. Also, not knowing some thing (how to find the Code Review > link in the https://phabricator.kde.org/ homepage) while being familiar with > another workflow doesn't mean that the first thing is hard, and the second > one not. > > > So I guess we have many different people in the community and many of > > them can get used to change. > > Everyone can get used to change; as long as the thing remains possible. > > > > * clone the repo > > > * hack > > > > * git commit > > * git push awesome-feature-branch > > So, basically, what you're saying is that unless a person has push rights, > they cannot collaborate? That's worse than I thought. In the Gitlab world, people would fork the main repository, work on their changes there and then send a merge request. To make it absolutely clear, push rights to main repositories are not required under any circumstances to contribute to a repository in the Gitlab world. For KDE Developers of course, they'll have the option of either forking the repository (like anyone else would for making changes) or working on a separate branch within the main repository. How projects want to work is up to them indvidually, but both models work - only non-developers are required to use forks. > > > * click on the link in the output > > > > > > > * add a bit of text explaining the change > > > * wait for me or dmitry to look at their patches > > > > One more step for the first creation of a merge request. Not that much > > different. > > > > > They don't have push access to kde's git server at all, so I guess > > > 'git push my-fork HEAD' won't work in any case. > > > > I guess this needs to change (with more fine grained permissions), the > > whole Merge Request System is based on merging other branches to Master. > > Afaik uploading just a patch doesn't work in GitLab. > > Well, that's too bad. Unless someone can explain to me how people can submit > patches for review without having push rights, a migration seems impossible. > It's already hard for some people to understand they need to create a KDE > identity, but once they've got that, they should be able to offer patches for > review. > > -- > https://www.valdyas.org | https://www.krita.org > > Cheers, Ben
Re: Gitlab Evaluation & Migration
I'm not an active contributor. I am a developer though, who's employer uses gitlab... Not a huge fan. My main complaint is it tends to be slow, and I find the UI a little less intuitive. Recently they even broke copy and paste site wide on their instance -- which was very frustrating. I recently stumbled upon this project: https://github.com/go-gitea/gitea I would pose it as an alternative that's very familiar feeling to GitHub, and written in a much more efficient language (Go vs Ruby), which should result in a lower operating cost. I want to be clear, I am very appreciative that many projects have been working to evaluate GitLab, and I don't think it's the worst option. I just wanted to pose this as well to the community as well. More informatively than anything else. Best, Wyatt On Sat, Feb 23, 2019, 9:14 AM Ben Cooksley On Sun, Feb 24, 2019 at 8:06 AM Boudewijn Rempt wrote: > > > > On zaterdag 23 februari 2019 18:58:46 CET ste...@derkits.at wrote: > > > > > "A lot" is probably a bit exaggerated, e.g. I don't really know where > to > > > upload patches to Phabricator or create a pull request there, but do > > > understand how GitLab works. > > > > I was talking about the Krita community, which uses Phabricator > extensively in this way. I don't think you're familiar enough with the > Krita community to make this comment. Also, not knowing some thing (how to > find the Code Review link in the https://phabricator.kde.org/ homepage) > while being familiar with another workflow doesn't mean that the first > thing is hard, and the second one not. > > > > > So I guess we have many different people in the community and many of > > > them can get used to change. > > > > Everyone can get used to change; as long as the thing remains possible. > > > > > > * clone the repo > > > > * hack > > > > > > * git commit > > > * git push awesome-feature-branch > > > > So, basically, what you're saying is that unless a person has push > rights, they cannot collaborate? That's worse than I thought. > > In the Gitlab world, people would fork the main repository, work on > their changes there and then send a merge request. > To make it absolutely clear, push rights to main repositories are not > required under any circumstances to contribute to a repository in the > Gitlab world. > > For KDE Developers of course, they'll have the option of either > forking the repository (like anyone else would for making changes) or > working on a separate branch within the main repository. How projects > want to work is up to them indvidually, but both models work - only > non-developers are required to use forks. > > > > > > * click on the link in the output > > > > > > > > > > * add a bit of text explaining the change > > > > * wait for me or dmitry to look at their patches > > > > > > One more step for the first creation of a merge request. Not that much > > > different. > > > > > > > They don't have push access to kde's git server at all, so I guess > > > > 'git push my-fork HEAD' won't work in any case. > > > > > > I guess this needs to change (with more fine grained permissions), the > > > whole Merge Request System is based on merging other branches to > Master. > > > Afaik uploading just a patch doesn't work in GitLab. > > > > Well, that's too bad. Unless someone can explain to me how people can > submit patches for review without having push rights, a migration seems > impossible. It's already hard for some people to understand they need to > create a KDE identity, but once they've got that, they should be able to > offer patches for review. > > > > -- > > https://www.valdyas.org | https://www.krita.org > > > > > > Cheers, > Ben >
Re: Gitlab Evaluation & Migration
On Saturday, 23 February 2019 21:12:08 GMT Wyatt Childers wrote: > I'm not an active contributor. I am a developer though, who's employer uses > gitlab... Not a huge fan. My main complaint is it tends to be slow, and I > find the UI a little less intuitive. Recently they even broke copy and > paste site wide on their instance -- which was very frustrating. > > I recently stumbled upon this project: https://github.com/go-gitea/gitea > > I would pose it as an alternative that's very familiar feeling to GitHub, > and written in a much more efficient language (Go vs Ruby), which should > result in a lower operating cost. > > I want to be clear, I am very appreciative that many projects have been > working to evaluate GitLab, and I don't think it's the worst option. I just > wanted to pose this as well to the community as well. More informatively > than anything else. > > Best, > > Wyatt Perhaps it's unjustified, but whenever someone mentions Gitea the first thing I notice is that *its own developers* host their project on GitHub... It seems odd to rely on a proprietary service instead of their own product that's supposed to be a direct replacement for it, and doesn't imply great confidence in the latter. - Francis
Re: Gitlab Evaluation & Migration
сб, 23 февр. 2019 г. в 12:44, Ben Cooksley : > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? Hi, 1. We migrated from github.com to self-hosted GitLab when I worked full-time in a team of 4 developers. A major drawback we noticed back then was slow page loading when browsing a large diff (e.g. in a merge request). For example, this commit takes around 15 seconds to load: https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 . We had load times of over 30 seconds for a real-world merge request in a proprietary project of our team, however it depends on the server-side hardware. 2. My other concern is the risk of uncontrolled creation of new branches because with GitLab they are created in the central repo for every new patch/feature. A repo may end up with dozens of branches of unclear status. The branch-per-feature approach works well for a small team of full-time developers since you can easily ask your colleagues "OK to delete this branch?" at any time and keep the repo as clean as you want. For >1000 people having write access (and who may become unavailable without notice), the same won't work. 3. Also, after moving to self-hosted GitLab, KDE's Git hosting will get the same familiar look and feel like github.com/gitlab.com/bitbucket, which may encourage random people to use it for anything (and their photo archives and more). Do we have the same infrastructure and administrative resources like GitHub has to overcome spam/abuse? Even a fair user may create scratch repo/branch and forget about it, thousands of such users may easily turn our Git hosting into a landfill. I know we had scratch repos before, but the steps to create them weren't as well-known and accessible as with GitLab. I believe, this is why we only have a limited number of scratch repos as of today. -- Alexander Potashev
Re: Gitlab Evaluation & Migration
On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev wrote: > > сб, 23 февр. 2019 г. в 12:44, Ben Cooksley : > > Based on all of the above we'd like to propose migrating towards > > Gitlab. Comments? > > Hi, Hi Alexander, > > 1. We migrated from github.com to self-hosted GitLab when I worked > full-time in a team of 4 developers. A major drawback we noticed back > then was slow page loading when browsing a large diff (e.g. in a merge > request). For example, this commit takes around 15 seconds to load: > https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 That commit is massive and is far beyond what would be routine for a project to commit, so I think it's quite reasonable for the system to take a bit of time to process it. Loading that page right now using the web inspector shows it takes about 8 seconds to generate, followed by a further 4 seconds to download, which doesn't seem unreasonable for 3200 lines of changes, plus context, over 187 files - especially given it syntax highlights it. > . > > We had load times of over 30 seconds for a real-world merge request in > a proprietary project of our team, however it depends on the > server-side hardware. We have relatively decent hardware available, so I don't expect that to be an issue. > > 2. My other concern is the risk of uncontrolled creation of new > branches because with GitLab they are created in the central repo for > every new patch/feature. A repo may end up with dozens of branches of > unclear status. > > The branch-per-feature approach works well for a small team of > full-time developers since you can easily ask your colleagues "OK to > delete this branch?" at any time and keep the repo as clean as you > want. For >1000 people having write access (and who may become > unavailable without notice), the same won't work. It depends on the model you want to work with, as I mentioned in one of my earlier emails regarding how merge requests would work. Projects can choose one of two ways to do it (and even use both models simultaneously should they wish): 1) Use branch-per-feature / review-request, with the branches being housed in the main repository. 2) Use individual repository forks With either model, as part of submitting the merge request you are given the option to have the source branch removed when the merge request is approved, which will cleanup the repository the merge request is originated from. > > 3. Also, after moving to self-hosted GitLab, KDE's Git hosting will > get the same familiar look and feel like > github.com/gitlab.com/bitbucket, which may encourage random people to > use it for anything (and their photo archives and more). Do we have > the same infrastructure and administrative resources like GitHub has > to overcome spam/abuse? Other open source projects which have switched to Gitlab also allow repositories to be created freely and they have not had to deal with abuse problems. I don't see why we would be any different. > > Even a fair user may create scratch repo/branch and forget about it, > thousands of such users may easily turn our Git hosting into a > landfill. Because the repositories are under users own individual namespaces this won't pollute the listing of main repositories which are what everyone will be interested in. > > I know we had scratch repos before, but the steps to create them > weren't as well-known and accessible as with GitLab. I believe, this > is why we only have a limited number of scratch repos as of today. git@code:~$ cat projects-list/projects-to-anongit.list | wc -l 2380 git@code:~$ cat projects-list/projects-to-anongit.list | grep -v ^scratch/ | grep -v ^clones/ | wc -l 1030 git@code:~$ cat projects-list/projects-to-anongit.list | grep ^scratch/ | wc -l 985 git@code:~$ cat projects-list/projects-to-anongit.list | grep ^clones/ | wc -l 365 If we count scratch and clone repositories together, 57% of all repositories on our systems currently are "personal" repositories, so they're certainly not in limited use. > > -- > Alexander Potashev Cheers, Ben
Re: Gitlab Evaluation & Migration
> Perhaps it's unjustified, but whenever someone mentions Gitea the first thing I notice is that *its own developers* host their project on GitHub... > It seems odd to rely on a proprietary service instead of their own product that's supposed to be a direct replacement for it, and doesn't imply great confidence in the latter. I'd imagine this is more for historical reasons. Seems like they're working on this: https://gitea.com/gitea/gitea https://github.com/go-gitea/gitea/issues/1029 On Sat, Feb 23, 2019, 11:30 AM Francis Herne On Saturday, 23 February 2019 21:12:08 GMT Wyatt Childers wrote: > > I'm not an active contributor. I am a developer though, who's employer > uses > > gitlab... Not a huge fan. My main complaint is it tends to be slow, and I > > find the UI a little less intuitive. Recently they even broke copy and > > paste site wide on their instance -- which was very frustrating. > > > > I recently stumbled upon this project: https://github.com/go-gitea/gitea > > > > I would pose it as an alternative that's very familiar feeling to GitHub, > > and written in a much more efficient language (Go vs Ruby), which should > > result in a lower operating cost. > > > > I want to be clear, I am very appreciative that many projects have been > > working to evaluate GitLab, and I don't think it's the worst option. I > just > > wanted to pose this as well to the community as well. More informatively > > than anything else. > > > > Best, > > > > Wyatt > > Perhaps it's unjustified, but whenever someone mentions Gitea the first > thing I > notice is that *its own developers* host their project on GitHub... > > It seems odd to rely on a proprietary service instead of their own product > that's supposed to be a direct replacement for it, and doesn't imply great > confidence in the latter. > > - Francis > > >
Re: Gitlab Evaluation & Migration
вс, 24 февр. 2019 г. в 00:47, Ben Cooksley : > > On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev > wrote: > > > > сб, 23 февр. 2019 г. в 12:44, Ben Cooksley : > > > Based on all of the above we'd like to propose migrating towards > > > Gitlab. Comments? > > > > Hi, > > Hi Alexander, > > > > > 1. We migrated from github.com to self-hosted GitLab when I worked > > full-time in a team of 4 developers. A major drawback we noticed back > > then was slow page loading when browsing a large diff (e.g. in a merge > > request). For example, this commit takes around 15 seconds to load: > > https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 > > That commit is massive and is far beyond what would be routine for a > project to commit, so I think it's quite reasonable for the system to > take a bit of time to process it. > Loading that page right now using the web inspector shows it takes > about 8 seconds to generate, followed by a further 4 seconds to > download, which doesn't seem unreasonable for 3200 lines of changes, > plus context, over 187 files - especially given it syntax highlights > it. Hi Ben, The thing is, it's much slower than github - that's why we noticed the issue. I'm not sure if GitLab is slower than Phabricator, but at least it tries to feel fast and loads the whole diff incrementally, so that the first portion is available in less than 1 second. For reference, here is that same commit in 4 different web UIs: - https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 - https://github.com/KDE/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 - https://phabricator.kde.org/R158:aadd9305b0467fa39e5c84af606c7d9eb1568533?show_all=true - https://cgit.kde.org/kdenlive.git/commit/?id=aadd9305b0467fa39e5c84af606c7d9eb1568533 (cgit also has syntax highlighting :)) You are right merge requests as large as this commit are not common, but 1. Once you have a large merge request, maintainers will probably spend some days reviewing it and may be open the same diff page many times, thus multiplying the suffering. 2. Diffs that are 10x smaller that this one are common, and a 1.5 second loading time (15s / 10 = 1.5s) is still not very comfortable. 3. A merge request may comprise multiple commits (e.g. 20 commits) and it's handy to browse/review a squashed diff for the whole merge request, making the diff 20 times longer that an average commit diff. Reviewing of multi-commit merge requests is also available on GitHub, and it's still fast there unlike GitLab. -- Alexander Potashev
