Re: Gitlab Evaluation & Migration
On Sat, Mar 23, 2019 at 12:42 AM Milian Wolff wrote: > > On Donnerstag, 28. Februar 2019 07:02:03 CET Ben Cooksley wrote: > > On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne wrote: > > > On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote: > > > > On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein wrote > > > > > > > > > > > > > On 2/27/19 4:38 AM, Nate Graham wrote: > > > > > > It's really pretty nice. But Gitlab has a > > > > > > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 > > > > > > and 4, people without commit access won't just be able to start > > > > > > hacking with the source checkout that kdesrc-build downloads, or > > > > > > else they won't be able to push their branch to any remotes and > > > > > > create a Merge Request.> > > > > > > > No, this is not correct. > > > > > > > > > > When you have a local git repository (be it your own or a clone), it > > > > > can > > > > > interact with any number of remote git repositories. > > > > > > > > > > When you do `git clone `, git automatically adds > > > > > > > > > > as a remote named "origin" to the local repository. But what "origin" > > > > > points to can be changed at any time, or other remotes with other > > > > > names > > > > > can be added for pushing too. "origin" is just a convention. > > > > > > > > > > I.e. someone can totally do this: > > > > > 1. use kdesrc-build to clone stuff > > > > > 2. git checkout -b feature to make a feature branch > > > > > 3. hack > > > > > 4. make a private fork on gitlab > > > > > 5. push to their fork from the clone they've been working in > > > > > > > > > > It's not necessary to fork first and clone your fork to get started. > > > > > > > > Thanks Eike, that makes e a lot of sense. Going to the website to fork > > > > each repo for the first time still adds an additional manual step > > > > compared to the status quo, so it would be nice if we can get > > > > kdesrc-build so set up forks automatically. That would be really > > > > slick. > > > > > > That would be slick. I wonder if Gitlab exposes an API for that (ideally > > > something that doesn't involve kdesrc-build having to store your creds)? > > > Potentially this API > > > https://docs.gitlab.com/ee/api/projects.html#fork-project (though it's > > > documented for EE not CE)? > > > > The API for both EE and CE is identical, except for the functionality > > that is dependent on the edition of EE it is available in (which is > > only enabled if you are using that edition) > > With regards to credentials, you would need to give it an API Token yes. > > > > In terms of server load, it would be nice if the setup of forks was > > still something the developer had to initiate rather than being done > > automatically for every repository touched by kdesrc-build (I say this > > mainly as if we had 50 people fork just half of the mainline > > repositories we have, that's ~450GB of space used up - a massive > > scalability issue) > > Are you sure about this? Isn't gitlab using something like `git-new-workdir` > internally to save on the disk overhead? If not, then request it, that would > be an obvious optimization opportunity. I haven't checked, but at first glance it doesn't seem to do this (which would make sense, because you're actually able to have multiple Gitaly instances to store repositories for a single Gitlab instance). In any case, i'd rather that we used fork in a manner that makes sense rather than trying to optimise for something that ends up creating thousands of repositories which are never used. We should only be creating forks / repositories which are actually going to be used. > > Bye > > -- > Milian Wolff > m...@milianw.de > http://milianw.de Regards, Ben
Re: Gitlab Evaluation & Migration
On Donnerstag, 28. Februar 2019 07:02:03 CET Ben Cooksley wrote: > On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne wrote: > > On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote: > > > On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein wrote > > > > > > > > > > On 2/27/19 4:38 AM, Nate Graham wrote: > > > > > It's really pretty nice. But Gitlab has a > > > > > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 > > > > > and 4, people without commit access won't just be able to start > > > > > hacking with the source checkout that kdesrc-build downloads, or > > > > > else they won't be able to push their branch to any remotes and > > > > > create a Merge Request.> > > > > > > No, this is not correct. > > > > > > > > When you have a local git repository (be it your own or a clone), it > > > > can > > > > interact with any number of remote git repositories. > > > > > > > > When you do `git clone `, git automatically adds > > > > > > > > as a remote named "origin" to the local repository. But what "origin" > > > > points to can be changed at any time, or other remotes with other > > > > names > > > > can be added for pushing too. "origin" is just a convention. > > > > > > > > I.e. someone can totally do this: > > > > 1. use kdesrc-build to clone stuff > > > > 2. git checkout -b feature to make a feature branch > > > > 3. hack > > > > 4. make a private fork on gitlab > > > > 5. push to their fork from the clone they've been working in > > > > > > > > It's not necessary to fork first and clone your fork to get started. > > > > > > Thanks Eike, that makes e a lot of sense. Going to the website to fork > > > each repo for the first time still adds an additional manual step > > > compared to the status quo, so it would be nice if we can get > > > kdesrc-build so set up forks automatically. That would be really > > > slick. > > > > That would be slick. I wonder if Gitlab exposes an API for that (ideally > > something that doesn't involve kdesrc-build having to store your creds)? > > Potentially this API > > https://docs.gitlab.com/ee/api/projects.html#fork-project (though it's > > documented for EE not CE)? > > The API for both EE and CE is identical, except for the functionality > that is dependent on the edition of EE it is available in (which is > only enabled if you are using that edition) > With regards to credentials, you would need to give it an API Token yes. > > In terms of server load, it would be nice if the setup of forks was > still something the developer had to initiate rather than being done > automatically for every repository touched by kdesrc-build (I say this > mainly as if we had 50 people fork just half of the mainline > repositories we have, that's ~450GB of space used up - a massive > scalability issue) Are you sure about this? Isn't gitlab using something like `git-new-workdir` internally to save on the disk overhead? If not, then request it, that would be an obvious optimization opportunity. Bye -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Gitlab Evaluation & Migration
On woensdag 13 maart 2019 09:21:25 CET Eike Hein wrote: > In this thread there have been some qualms on "is GitLab maybe harder on > newbie devs", but this doesn't take into account the extremely awkward > dance we currently do where we ask people if they have dev access or not > and if they need help landing. Um... That's actually the point where we make newcomers aware that they can actually get deeper into the community. To me, it feels a bit like I imagine fishing must feel. Two, three nibbles, and they're hooked... -- https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Gitlab Evaluation & Migration
Same. One thing I like very much about GitLab is that it puts the onus of merging post-review on the *reviewer*. In this thread there have been some qualms on "is GitLab maybe harder on newbie devs", but this doesn't take into account the extremely awkward dance we currently do where we ask people if they have dev access or not and if they need help landing. In GitLab, once your MR is up there, and gets accepted, you're done - much smoother, no feeling of "you're not part of the team yet", etc. The reviewer just clicks "Merge" and it's in (no more fiddling with arc patch/land for the reviewer, either). If Rebase is really convenient for reviewers (the button), that's more likely to stay that nice, because people don't get asked "can you rebase this for me", either. It builds on the strength. Cheers, Eike On 3/12/19 7:05 PM, Andrius Štikonas wrote: Note that you can still do rebase merge manually. Gitlab can show the list of commands that you need to run. In that list just replace git merge with rebase. But I also prefer to just have a button. Regards, Andrius On 2019-03-12 04:46, Eike Hein wrote: On 3/12/19 7:46 AM, Albert Astals Cid wrote: I asked for this too, i thought it had been enabled at some point, but i guess not. So +1 Seems it's currently being done on-demand, per-repo. The ticket I linked has a Rails snippet for doing it for all projects, which sysadmin may find useful. Cheers, Albert Cheers, Eike
Re: Gitlab Evaluation & Migration
Note that you can still do rebase merge manually. Gitlab can show the list of commands that you need to run. In that list just replace git merge with rebase. But I also prefer to just have a button. Regards, Andrius On 2019-03-12 04:46, Eike Hein wrote: On 3/12/19 7:46 AM, Albert Astals Cid wrote: I asked for this too, i thought it had been enabled at some point, but i guess not. So +1 Seems it's currently being done on-demand, per-repo. The ticket I linked has a Rails snippet for doing it for all projects, which sysadmin may find useful. Cheers, Albert Cheers, Eike
Re: Gitlab Evaluation & Migration
On 3/12/19 7:46 AM, Albert Astals Cid wrote: I asked for this too, i thought it had been enabled at some point, but i guess not. So +1 Seems it's currently being done on-demand, per-repo. The ticket I linked has a Rails snippet for doing it for all projects, which sysadmin may find useful. Cheers, Albert Cheers, Eike
Re: Gitlab Evaluation & Migration
El dilluns, 11 de març de 2019, a les 22:46:33 CET, Eike Hein va escriure: > Hi, > > I have a request. > > In the evaluation lately, I've seen some people unhappy with the merge > commits created when merging merge requests that can't be > fast-forwarded, as it clutters the repo history. While I personally > don't mind much, I can see the point coming from the squash-and-rebase > workflow Phabricator had. > > It turns out that GitLab has a feature to disallow non-fast-forward > merges and show a rebase button instead: > > https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html > > https://gitlab.com/gitlab-org/gitlab-ce/issues/20076 > > Could we enable this? I asked for this too, i thought it had been enabled at some point, but i guess not. So +1 Cheers, Albert > > > Cheers, > Eike >
Re: Gitlab Evaluation & Migration
Hi, I have a request. In the evaluation lately, I've seen some people unhappy with the merge commits created when merging merge requests that can't be fast-forwarded, as it clutters the repo history. While I personally don't mind much, I can see the point coming from the squash-and-rebase workflow Phabricator had. It turns out that GitLab has a feature to disallow non-fast-forward merges and show a rebase button instead: https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html https://gitlab.com/gitlab-org/gitlab-ce/issues/20076 Could we enable this? Cheers, Eike
Re: Gitlab Evaluation & Migration
Implementation details talk seems better suited for #kde-sysadmin :-) In any case, _automatically_ creating forks doesn't sound wise to me with my engineering hat on, because it's unnecessary. To create a fork, kdesrc-build would need authenticated API access. If it has has that, it can use it at any time. For example, if could have a command like this: $ kdesrc-build dev ... which then: - puts a nice commit template into the repo - asks the username / does API auth - uses the API to create the fork - adds the remote Again though: This is taking us far off-topic. Cheers, Eike
Re: Gitlab Evaluation & Migration
On Thu, Feb 28, 2019 at 9:43 PM Ben Cooksley wrote: > On Fri, Mar 1, 2019 at 3:13 AM Nate Graham wrote: > > > > On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley > wrote > > > In terms of server load, it would be nice if the setup of forks was > > > still something the developer had to initiate rather than being done > > > automatically for every repository touched by kdesrc-build (I say this > > > mainly as if we had 50 people fork just half of the mainline > > > repositories we have, that's ~450GB of space used up - a massive > > > scalability issue) > > > > This seems like a challenge that needs to be addressed regardless of > whether or not kdesrc-build does it automatically, because people creating > tons and tons of forks is guaranteed to happen anyway if we move to Gitlab. > It seems non-optimal if having more people able to submit merge requests > results in the potential to blow up our servers. > > We have a little over 1,000 mainline repositories, so in the above > example we'd be talking about 25,000 forks being created - and i'd be > expecting quite a bit more than 50 people to use kdesrc-build. To use > another scenario, if the metric of half the repositories being > involved (or even a quarter) held true with say 300 users, you're now > looking at 75,000 - 150,000 forked repositories (and probably around > 1.4TB - 2.7TB of space used) courtesy of an automated tool. > > It would take quite a while for us to reach 150,000 forked > repositories on Gitlab if humans were to be creating these manually, > however if an automated tool is going to be creating them as part of > it's workflow, then we will hit it much more quickly (and is a > phenomenal waste of resources given virtually all of those forks will > never be utilised) > I wonder if advanced filesystem features like ZFS deduplication may help in this situation. > I certainly do expect a number of forks to be created yes, but i'd > rather they be useful forks where someone at least intends on working > on something, rather than ones created automatically by software "just > in case" someone decides to work on a project. > > > > > Nate > > > > Cheers, > Ben >
Re: Gitlab Evaluation & Migration
On Fri, Mar 1, 2019 at 3:13 AM Nate Graham wrote: > > On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley > wrote > > In terms of server load, it would be nice if the setup of forks was > > still something the developer had to initiate rather than being done > > automatically for every repository touched by kdesrc-build (I say this > > mainly as if we had 50 people fork just half of the mainline > > repositories we have, that's ~450GB of space used up - a massive > > scalability issue) > > This seems like a challenge that needs to be addressed regardless of whether > or not kdesrc-build does it automatically, because people creating tons and > tons of forks is guaranteed to happen anyway if we move to Gitlab. It seems > non-optimal if having more people able to submit merge requests results in > the potential to blow up our servers. We have a little over 1,000 mainline repositories, so in the above example we'd be talking about 25,000 forks being created - and i'd be expecting quite a bit more than 50 people to use kdesrc-build. To use another scenario, if the metric of half the repositories being involved (or even a quarter) held true with say 300 users, you're now looking at 75,000 - 150,000 forked repositories (and probably around 1.4TB - 2.7TB of space used) courtesy of an automated tool. It would take quite a while for us to reach 150,000 forked repositories on Gitlab if humans were to be creating these manually, however if an automated tool is going to be creating them as part of it's workflow, then we will hit it much more quickly (and is a phenomenal waste of resources given virtually all of those forks will never be utilised) I certainly do expect a number of forks to be created yes, but i'd rather they be useful forks where someone at least intends on working on something, rather than ones created automatically by software "just in case" someone decides to work on a project. > > Nate > Cheers, Ben
Re: Gitlab Evaluation & Migration
On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley wrote > In terms of server load, it would be nice if the setup of forks was > still something the developer had to initiate rather than being done > automatically for every repository touched by kdesrc-build (I say this > mainly as if we had 50 people fork just half of the mainline > repositories we have, that's ~450GB of space used up - a massive > scalability issue) This seems like a challenge that needs to be addressed regardless of whether or not kdesrc-build does it automatically, because people creating tons and tons of forks is guaranteed to happen anyway if we move to Gitlab. It seems non-optimal if having more people able to submit merge requests results in the potential to blow up our servers. Nate
Re: Gitlab Evaluation & Migration
On Thu, Feb 28, 2019 at 10:23 PM Filipe Saraiva wrote: > > Em 24/02/2019 22:25, Filipe Saraiva escreveu: > > > > 4. Is there any date to officially start the migration for all projects? > > How will it be? > > > > Will the migration happen before GSoC? Is it possible to a project > request for migration and set Gitlab in the time for GSoC? There is quite a bit of infrastructural work that will need to be done should the consensus conclusion be that we should be migrating. As such there is no guarantee that the migration will be in progress or complete by the time GSoC starts. Given we're still in early discussion on this, no policy around how projects not involved in the evaluation can opt in early has yet been made. > > -- > Filipe Saraiva > http://filipesaraiva.info/ Regards, Ben
Re: Gitlab Evaluation & Migration
Em 24/02/2019 22:25, Filipe Saraiva escreveu: > > 4. Is there any date to officially start the migration for all projects? > How will it be? > Will the migration happen before GSoC? Is it possible to a project request for migration and set Gitlab in the time for GSoC? -- Filipe Saraiva http://filipesaraiva.info/
Re: Gitlab Evaluation & Migration
On Thu, Feb 28, 2019 at 11:24 AM Albert Astals Cid wrote: > > El dimecres, 27 de febrer de 2019, a les 20:12:55 CET, Eike Hein va escriure: > > > > On 2/27/19 4:38 AM, Nate Graham wrote: > > > It's really pretty nice. But Gitlab has a > > > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, > > > people without commit access won't just be able to start hacking with the > > > source checkout that kdesrc-build downloads, or else they won't be able > > > to push their branch to any remotes and create a Merge Request. > > > > No, this is not correct. > > Can we enable the upload diff by email option? I know it's not the best UI > but for some people that have trouble understanding git remotes it may help? > > https://docs.gitlab.com/ee/user/project/merge_requests/#create-new-merge-requests-by-email For ease of deployment, we didn't enable the email interface for the evaluation instance. As it's likely we would end up setting up the email interface for a full production instance, this would be enabled as part of that. > > Cheers, > Albert > > Regards, Ben
Re: Gitlab Evaluation & Migration
On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne wrote: > > On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote: > > On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein wrote > > > On 2/27/19 4:38 AM, Nate Graham wrote: > > > > It's really pretty nice. But Gitlab has a > > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, > > people without commit access won't just be able to start hacking with the > > source checkout that kdesrc-build downloads, or else they won't be able to > > push their branch to any remotes and create a Merge Request. > > > > > > No, this is not correct. > > > > > > When you have a local git repository (be it your own or a clone), it can > > > interact with any number of remote git repositories. > > > > > > When you do `git clone `, git automatically adds > > > as a remote named "origin" to the local repository. But what "origin" > > > points to can be changed at any time, or other remotes with other names > > > can be added for pushing too. "origin" is just a convention. > > > > > > I.e. someone can totally do this: > > > 1. use kdesrc-build to clone stuff > > > 2. git checkout -b feature to make a feature branch > > > 3. hack > > > 4. make a private fork on gitlab > > > 5. push to their fork from the clone they've been working in > > > > > > It's not necessary to fork first and clone your fork to get started. > > > > Thanks Eike, that makes e a lot of sense. Going to the website to fork > > each repo for the first time still adds an additional manual step > > compared to the status quo, so it would be nice if we can get > > kdesrc-build so set up forks automatically. That would be really > > slick. > > That would be slick. I wonder if Gitlab exposes an API for that (ideally > something that doesn't involve kdesrc-build having to store your creds)? > Potentially this API > https://docs.gitlab.com/ee/api/projects.html#fork-project (though it's > documented for EE not CE)? The API for both EE and CE is identical, except for the functionality that is dependent on the edition of EE it is available in (which is only enabled if you are using that edition) With regards to credentials, you would need to give it an API Token yes. In terms of server load, it would be nice if the setup of forks was still something the developer had to initiate rather than being done automatically for every repository touched by kdesrc-build (I say this mainly as if we had 50 people fork just half of the mainline repositories we have, that's ~450GB of space used up - a massive scalability issue) > > Regards, > - Michael Pyne Cheers, Ben
Re: Gitlab Evaluation & Migration
On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote: > On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein wrote > > On 2/27/19 4:38 AM, Nate Graham wrote: > > > It's really pretty nice. But Gitlab has a > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, > people without commit access won't just be able to start hacking with the > source checkout that kdesrc-build downloads, or else they won't be able to > push their branch to any remotes and create a Merge Request. > > > > No, this is not correct. > > > > When you have a local git repository (be it your own or a clone), it can > > interact with any number of remote git repositories. > > > > When you do `git clone `, git automatically adds > > as a remote named "origin" to the local repository. But what "origin" > > points to can be changed at any time, or other remotes with other names > > can be added for pushing too. "origin" is just a convention. > > > > I.e. someone can totally do this: > > 1. use kdesrc-build to clone stuff > > 2. git checkout -b feature to make a feature branch > > 3. hack > > 4. make a private fork on gitlab > > 5. push to their fork from the clone they've been working in > > > > It's not necessary to fork first and clone your fork to get started. > > Thanks Eike, that makes e a lot of sense. Going to the website to fork > each repo for the first time still adds an additional manual step > compared to the status quo, so it would be nice if we can get > kdesrc-build so set up forks automatically. That would be really > slick. That would be slick. I wonder if Gitlab exposes an API for that (ideally something that doesn't involve kdesrc-build having to store your creds)? Potentially this API https://docs.gitlab.com/ee/api/projects.html#fork-project (though it's documented for EE not CE)? Regards, - Michael Pyne
Re: Gitlab Evaluation & Migration
Hey, I've been part of the evaluation with KDE Connect. My experience has been mostly good with a small exception: I personally prefer the push-to-branch model over the fork model, but when trying it with KDE Connect pushing to a branch created IRC commit notifications which caused a lot of noise in the channel. Disabling commit notifications for branches other than master and stable would solve that. Other than that I had no issues that were not already mentioned. +1 from me. Cheers Nico On Samstag, 23. Februar 2019 10:44:11 CET 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. 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
El dimecres, 27 de febrer de 2019, a les 20:12:55 CET, Eike Hein va escriure: > > On 2/27/19 4:38 AM, Nate Graham wrote: > > It's really pretty nice. But Gitlab has a > > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, > > people without commit access won't just be able to start hacking with the > > source checkout that kdesrc-build downloads, or else they won't be able to > > push their branch to any remotes and create a Merge Request. > > No, this is not correct. Can we enable the upload diff by email option? I know it's not the best UI but for some people that have trouble understanding git remotes it may help? https://docs.gitlab.com/ee/user/project/merge_requests/#create-new-merge-requests-by-email Cheers, Albert
Re: Gitlab Evaluation & Migration
On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein wrote > On 2/27/19 4:38 AM, Nate Graham wrote: > > It's really pretty nice. But Gitlab has a > > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, > > people without commit access won't just be able to start hacking with the > > source checkout that kdesrc-build downloads, or else they won't be able to > > push their branch to any remotes and create a Merge Request. > > No, this is not correct. > > When you have a local git repository (be it your own or a clone), it can > interact with any number of remote git repositories. > > When you do `git clone `, git automatically adds > as a remote named "origin" to the local repository. But what "origin" > points to can be changed at any time, or other remotes with other names > can be added for pushing too. "origin" is just a convention. > > I.e. someone can totally do this: > 1. use kdesrc-build to clone stuff > 2. git checkout -b feature to make a feature branch > 3. hack > 4. make a private fork on gitlab > 5. push to their fork from the clone they've been working in > > It's not necessary to fork first and clone your fork to get started. Thanks Eike, that makes e a lot of sense. Going to the website to fork each repo for the first time still adds an additional manual step compared to the status quo, so it would be nice if we can get kdesrc-build so set up forks automatically. That would be really slick. Nate
Re: Gitlab Evaluation & Migration
On 2/27/19 4:38 AM, Nate Graham wrote: It's really pretty nice. But Gitlab has a fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, people without commit access won't just be able to start hacking with the source checkout that kdesrc-build downloads, or else they won't be able to push their branch to any remotes and create a Merge Request. No, this is not correct. When you have a local git repository (be it your own or a clone), it can interact with any number of remote git repositories. When you do `git clone `, git automatically adds as a remote named "origin" to the local repository. But what "origin" points to can be changed at any time, or other remotes with other names can be added for pushing too. "origin" is just a convention. I.e. someone can totally do this: 1. use kdesrc-build to clone stuff 2. git checkout -b feature to make a feature branch 3. hack 4. make a private fork on gitlab 5. push to their fork from the clone they've been working in It's not necessary to fork first and clone your fork to get started. When I do a private fork of a repo on the existing git.kde.org (if you look at the manual, we actually do have that, albeit called "personal clone" in the docs) I usually keep it as a second remote in my clone of the main repo, too. Since the URLs of forks in GitLab are predictable (provided the username is known), we could have kdesrc-build do that automatically. It could also add some sort of contribution script or hook for that matter to each clone, if we want more automagic. Takeaway: It's pretty important that if we decide to migrate to GitLab, we should schedule and plan it in a way that allows us to come together and consider and debate what it would mean, what would happen, and what needs to be prepared for it. Things like the contribution workflow and the docs for it would need to be ready. The Onboarding sprint might be a good venue for that. Cheers, Eike
Re: Gitlab Evaluation & Migration
On Wed, Feb 27, 2019 at 5:18 AM Harald Sitter wrote: > > On Mon, Feb 25, 2019 at 2:38 PM Boudewijn Rempt wrote: > > > > On zaterdag 23 februari 2019 12:08:05 CET Boudewijn Rempt wrote: > > > > > * 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. > > > > Another thing here: what would be a good way to keep the really valuable > > information we've put in our tasks available? We have been tracking some > > big projects in phab's task system, and that information would be really > > hard to lose, but it would also rather suck to have to convert that > > manually to wiki pages or whatever... > > I suppose I could be persuaded to migrate all tasks again ;) > As Eike mentioned the current boards feature is fairly limited though, > so that may complicate things (a lot). Fortunately we've already been linked to work done by others (FD.o, GNOME, etc), so hopefully it'll just be a case of testing it on our data, fixing any minor things we come across, then performing the actual live migration :) I haven't looked too much into that though as I wanted confirmation we were going to undertake a migration before focusing on getting this working 100%. > > HS Cheers, Ben
Re: Gitlab Evaluation & Migration
On Tue, 26 Feb 2019 02:02:08 -0700 Eike Hein wrote > How would GitLab impact the kdesrc-build experience? So this is the current kdesrc-build experience: 1. kdesrc-build [thing] 2. cd ~/kde/src[thing] 3. arc feature my-awesome-patch 4. Start hacking 5. kdesrc-build --no-src --resume-from [thing] 6. [test and make sure it works] 7. arc diff --create It's really pretty nice. But Gitlab has a fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, people without commit access won't just be able to start hacking with the source checkout that kdesrc-build downloads, or else they won't be able to push their branch to any remotes and create a Merge Request. Since Merge Requests from people without commit access have to come from a private fork, that means that in the above model, they need to use some web UI to first create a private fork, and then somehow tell kdesrc-build to check that out rather than the original repo. Alternatively, perhaps kdesrc-build could check out the source from the original repo, but automatically create a second remote in each repo that corresponds to the private fork? Then people could hack in the original repo, but push their branches to the private remote fork for the purposes of creating a Merge Request. All of this is probably technically solvable, but it seems like it will take some doing to ensure that the user experience is as good as it currently is today (IMO, of course!). Nate
Re: Gitlab Evaluation & Migration
On Tue, Feb 26, 2019 at 10:37 AM Eike Hein wrote: > > > > On 2/26/19 6:26 PM, b...@valdyas.org wrote: > > * I've seen one workboard per project, that's not ideal, otoh, the Krita > > community early on went overboard with workboards, so we can make do > > with that > > I consider this one a blocker +1
Re: Gitlab Evaluation & Migration
On Mon, Feb 25, 2019 at 2:38 PM Boudewijn Rempt wrote: > > On zaterdag 23 februari 2019 12:08:05 CET Boudewijn Rempt wrote: > > > * 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. > > Another thing here: what would be a good way to keep the really valuable > information we've put in our tasks available? We have been tracking some big > projects in phab's task system, and that information would be really hard to > lose, but it would also rather suck to have to convert that manually to wiki > pages or whatever... I suppose I could be persuaded to migrate all tasks again ;) As Eike mentioned the current boards feature is fairly limited though, so that may complicate things (a lot). HS
Re: Gitlab Evaluation & Migration
Hello, On Sat, 23 Feb 2019, at 10:44, Ben Cooksley wrote: > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? Just a small FYI from the migration of the VideoLAN community. We're moving almost everything from git/gitosis, jenkins, trac, patchwork, mediawiki, gitweb to gitlab and gitlab-ci. We have projects that are very very classical (ML + Patches, with people using only mutt to read) to projects that are MR-only, with no mailing lists at all. So far, the model works for everyone. And the CI is a godsend, especially after working with jenkins. The only big downside, (besides some small bugs), is the bugtracker that is the usual "github issue" clone. Aka, not a bugtracker: no custom fields, no customization possible, horrible labeling system and people using it to track their issues (aka, I cannot read the documentation and read how to compile, which should be in the forum). So far, the gitlab team does not want to address those concerns, and will add the required features in the non-open source edition. The rest is great. Best, -- Jean-Baptiste Kempf - President +33 672 704 734
Re: Gitlab Evaluation & Migration
On Sat, Feb 23, 2019 at 10:45 AM Ben Cooksley wrote: > > Hi all, > > [...] > > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? Good decision. Hopefully the migration will start sooner than later. Thank you for all your work on that.
Re: Gitlab Evaluation & Migration
On Tue, Feb 26, 2019 at 10:26 PM wrote: > > On 2019-02-26 10:13, Ben Cooksley wrote: > > > No decision has been made, that's what this thread is about. > > I may have my personal views on what may be best, but that's all they > > are - my views. > > I might be one of the few KDE contributors who actively likes > phabricator, but I'm all for migrating. I've had a number of questions, > but those have all been answered satisfactorily. > > * can new contributors without push access to the main repos still > submit patches: yes > * is our phabricator history safe: yes > * I've seen one workboard per project, that's not ideal, otoh, the Krita > community early on went overboard with workboards, so we can make do > with that > * it's possible to add images to issues, so the lack of mockups isn't > that important -- we organized our mockups per task in any case > > I'm still not happy with how issue tracking and project management are > conflated, but I guess I can live with that, as long as we keep bugzilla > for user bug reports. At this time we do most definitely plan to keep Bugzilla for user bug reports. > > We discussed this topic at yesterday's weekly Krita meeting, and > everyone agreed that we are in favor of moving to gitlab. > > Boudewijn Cheers, Ben
Re: Gitlab Evaluation & Migration
On 2/26/19 6:26 PM, b...@valdyas.org wrote: * I've seen one workboard per project, that's not ideal, otoh, the Krita community early on went overboard with workboards, so we can make do with that I consider this one a blocker, and it's one of the things we've told GitLab we really want in the CE. Let's expand in on this. On Phab, we currently have boards like "Wayland" that contain issues from different projects. In the GitLab CE, it's currently only possible to have one board per project, and it's possible to put projects into a hierarchy. I.e. when all projects are sub-projects on a "KDE" one, it becomes possible to have a board at the "KDE" level that contains issues from different subprojects. But that means "Wayland" could be the only board, which is rubbish. I have every expectations we will get this. GitLab has once made public promise that they would not put arbitrary numeric limitations on the CE offering, and "one board per project" is an arbitrary numeric limitation vs. "as many boards as you want". Side note: GitLab also has a concept called "Epics" that's kind of like boards without the columns. We don't know yet, as a community, if we would use to use these and how, I guess, but they seem interesting. Boudewijn Cheers, Eike
Re: Gitlab Evaluation & Migration
On 2019-02-26 10:13, Ben Cooksley wrote: No decision has been made, that's what this thread is about. I may have my personal views on what may be best, but that's all they are - my views. I might be one of the few KDE contributors who actively likes phabricator, but I'm all for migrating. I've had a number of questions, but those have all been answered satisfactorily. * can new contributors without push access to the main repos still submit patches: yes * is our phabricator history safe: yes * I've seen one workboard per project, that's not ideal, otoh, the Krita community early on went overboard with workboards, so we can make do with that * it's possible to add images to issues, so the lack of mockups isn't that important -- we organized our mockups per task in any case I'm still not happy with how issue tracking and project management are conflated, but I guess I can live with that, as long as we keep bugzilla for user bug reports. We discussed this topic at yesterday's weekly Krita meeting, and everyone agreed that we are in favor of moving to gitlab. Boudewijn
Re: Gitlab Evaluation & Migration
On Tue, Feb 26, 2019 at 5:54 AM Martin Flöser wrote: > > Am 2019-02-24 21:03, schrieb Ben Cooksley: > > On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser > > wrote: > >> > >> Am 2019-02-23 10:44, schrieb Ben Cooksley: > >> > Hi all, > >> > >> > Based on all of the above we'd like to propose migrating towards > >> > Gitlab. Comments? > >> > >> I'm totally honest here: I'm not happy about yet another migration. > >> This > >> will be the fifth reviewing toolkit I use for KDE (reviewboard for > >> svn, > >> reviewboard for git, gerrit, phabricator and now gitlab). Each of the > >> transitions was painful for everyone involved and the commit rate to > >> the > >> project I was involved suffered from the transitions. As an example > >> for > >> the problems: KWin's hacking document still mentions reviewboard: > >> https://community.kde.org/KWin/Hacking#Submitting_Changes > > > > Please don't over exaggerate the numbers here. > > > > Gerrit was never an official system for reviews, it was something that > > was evaluated by a small group and which was never proceeded with as > > an official whole-of-KDE solution. > > Reviewboard for SVN/Git are basically the same thing (just a different > > instance url), so this is only really the third system, not the fifth > > You missed the point. What I wrote is that the transitions were painful > - also the very simple transition from svn.reviewboard to > git.reviewboard was painful. That it was the same tool doesn't matter. > It was still a transition, it meant looking at two places, lost reviews, > update to documentation, change of workflow, etc. etc. > > Also gerrit was a tool I used for KDE hacking. I wrote it will be the > fifth toolkit for me. That's true for me and I don't over exaggerate any > numbers here. > > > > > Please also bear in mind that we've been on Git now for coming up on 9 > > years (I have mails for git.kde.org starting around June 2010) so > > switching systems twice in that time frame as software continues to > > mature seems quite reasonable to me. > > Please keep also in mind that the git transition took a long time and > started for different projects at different times. That you as sysadmin > had mails going back so long does not mean others as well. I consider it > as a transition too early after Phabricator was praised so much. I was > sure that this would be a solution for the next decade. > Unfortunately this has turned out not to be the case, due to changing needs of the community. > > > >> > >> I'm not pleased that we want to transit to another solution after just > >> a > >> few years. I understand that there is the feeling that our phabricator > >> solution limits contributions from newcomers. I don't believe that and > >> are afraid of the long term developers walking away due to the changes > >> (which is something I saw with every transition). I don't know whether > >> I > >> will continue to contribute if I have to relearn the tooling - my time > >> for KDE is currently very limited. If I have an hour to hack and have > >> to > >> spend half the time on how to contribute now, that sucks and lowers > >> motivation. > > > > If you've worked with Github before then Gitlab is very similar, so > > the learning curve shouldn't be too steep. > > I haven't worked with github. > > > > >> > >> Changing the tooling will not solve any of the contribution problems. > >> Instead we introduce new ones like all documentation going out of > >> life. > >> > >> Please consider whether the advantages are really worth it. > > > > Please also see my comments re. Phabricator upstream as to part of the > > reason why we're considering this, along with the feedback we received > > at Akademy last year. > > Well I remember how phabricator was praised for the very responsive > team. That seems to have changed. But who guarantees that gitlab will > continue to be responsive and cooperative? Will we have to switch again > if the team stops to be responsive? > > You asked for comments. I gave comment that I'm not pleased about yet > another transition. Please keep that in mind. It means learning and > interrupted workflows for every one. If you have already decided and > don't want anybody to point out that transitions are painful, please > don't ask for comments. Instead say that sysadmins decided. That's at > least honest - your reply gives me the feeling the decision is already > done and negative feedback was not expected. Sorry to feel this way. Undertaking the process of transitioning from one tool to another is not something we do lightly, as it not only involves disruption for people who have to switch to a new set of tools, but also requires substantial changes to the infrastructure (I will note that Phabricator never took over hosting of our repositories) No decision has been made, that's what this thread is about. I may have my personal views on what may be best, but that's all they are - my views. > > Cheers > Martin Regards, Ben
Re: Gitlab Evaluation & Migration
On Tue, Feb 26, 2019 at 10:02 PM Eike Hein wrote: > > > > On 2/26/19 4:17 AM, Nate Graham wrote: > > Like you, I have some reservations about Gitlab. I'm not thrilled about > > losing approve/request changes statuses (that's in the EE edition only > > right now). > > Me too. It's one of the things we're asking to be moved to the CE -- and > so is Gnome. GitLab knows we're talking to each other and doubling down > on this need. > > > > the kdesrc-build experience > > How would GitLab impact the kdesrc-build experience? > > > > Landing patches is time-consuming and error-prone. > > Yes. As a maintainer of things I often land patches by new contributors > without dev access, and it's super annoying and painful. `arc patch`, > remember to correct author info, merge around, ... > > > > Phab's system that attempts (and fails) to abstract away Git itself > > I think Phab was originally written for SVN - it shows I guess. I can confirm that Phabricator was originally written for SVN (as that is what is used internally at Facebook). The ability to have Phabricator host repositories was something it only gained around the time we started looking at migrating to it. Prior to that it had exclusively been a repository viewer and code review tool (and I suspect the code review part predates the repository viewer component) > > > Cheers, > Eike Cheers, Ben
Re: Gitlab Evaluation & Migration
On 2/26/19 4:17 AM, Nate Graham wrote: Like you, I have some reservations about Gitlab. I'm not thrilled about losing approve/request changes statuses (that's in the EE edition only right now). Me too. It's one of the things we're asking to be moved to the CE -- and so is Gnome. GitLab knows we're talking to each other and doubling down on this need. > the kdesrc-build experience How would GitLab impact the kdesrc-build experience? > Landing patches is time-consuming and error-prone. Yes. As a maintainer of things I often land patches by new contributors without dev access, and it's super annoying and painful. `arc patch`, remember to correct author info, merge around, ... > Phab's system that attempts (and fails) to abstract away Git itself I think Phab was originally written for SVN - it shows I guess. Cheers, Eike
Re: Gitlab Evaluation & Migration
On Mon, 25 Feb 2019 09:54:26 -0700 Martin Flöser wrote > You asked for comments. I gave comment that I'm not pleased about yet > another transition. Please keep that in mind. It means learning and > interrupted workflows for every one. If you have already decided and > don't want anybody to point out that transitions are painful, please > don't ask for comments. Instead say that sysadmins decided. That's at > least honest - your reply gives me the feeling the decision is already > done and negative feedback was not expected. Sorry to feel this way. I think it goes without saying that transitions are painful, so it doesn't seem necessary to point this out because it's obvious to anyone who's ever undergone a transition. The point of any transition is that the pleasure of the new system should outweigh the temporary pain involved in transitioning, and the permanent the pain imposed by the current system. Like you, I have some reservations about Gitlab. I'm not thrilled about losing approve/request changes statuses (that's in the EE edition only right now). And gitlab's fork-the-repo workflow feels more awkward to me than Phab's patch-based workflow, and I have some questions regarding scalability and the kdesrc-build experience given that each of our 80+ frameworks has its own repo. There are also some UI issues associated with inline comments in merge requests that I'd like to see fixed. But there is a lot of pain currently associated with Phab. Multi-commit chains are very difficult to do correctly. Updating patches to reflect changes in the origin is error-prone. The website's user interface and search are poor. Landing patches is time-consuming and error-prone. The review experience for patches that change SVG icons is terrible, and occasionally suffers from a bug that that makes certain patches impossible to review [1]. All of these issues are fixed with Gitlab in my experience testing our our evaluation instance on https://invent.kde.org. Have you had a chance to try it out yet? I didn't notice any comments from you in https://notes.kde.org/p/gitlab-evaluation-notes And I think there's value in listening to the outside world when people tell us that they prefer Gitlab's workflow to Phab's system that attempts (and fails) to abstract away Git itself. The enormous popularity of Github means that this workflow is at the very least familiar to a huge amount of developers, if not outright superior. If we ignore that, we risk losing newcomers over time because our system is just weird and awkward compared to the norm, no matter how good our documentation is--and I think it's pretty darn good right now. And yes, the documentation will go stale and need to be updated. I'll do this for Gitlab just like I did for Phab [2]. [1] https://secure.phabricator.com/T1022 [2] https://community.kde.org/index.php?title=Infrastructure/Phabricator=history). Nate
Re: Gitlab Evaluation & Migration
Am 2019-02-24 21:03, schrieb Ben Cooksley: On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser wrote: Am 2019-02-23 10:44, schrieb Ben Cooksley: > Hi all, > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? I'm totally honest here: I'm not happy about yet another migration. This will be the fifth reviewing toolkit I use for KDE (reviewboard for svn, reviewboard for git, gerrit, phabricator and now gitlab). Each of the transitions was painful for everyone involved and the commit rate to the project I was involved suffered from the transitions. As an example for the problems: KWin's hacking document still mentions reviewboard: https://community.kde.org/KWin/Hacking#Submitting_Changes Please don't over exaggerate the numbers here. Gerrit was never an official system for reviews, it was something that was evaluated by a small group and which was never proceeded with as an official whole-of-KDE solution. Reviewboard for SVN/Git are basically the same thing (just a different instance url), so this is only really the third system, not the fifth You missed the point. What I wrote is that the transitions were painful - also the very simple transition from svn.reviewboard to git.reviewboard was painful. That it was the same tool doesn't matter. It was still a transition, it meant looking at two places, lost reviews, update to documentation, change of workflow, etc. etc. Also gerrit was a tool I used for KDE hacking. I wrote it will be the fifth toolkit for me. That's true for me and I don't over exaggerate any numbers here. Please also bear in mind that we've been on Git now for coming up on 9 years (I have mails for git.kde.org starting around June 2010) so switching systems twice in that time frame as software continues to mature seems quite reasonable to me. Please keep also in mind that the git transition took a long time and started for different projects at different times. That you as sysadmin had mails going back so long does not mean others as well. I consider it as a transition too early after Phabricator was praised so much. I was sure that this would be a solution for the next decade. I'm not pleased that we want to transit to another solution after just a few years. I understand that there is the feeling that our phabricator solution limits contributions from newcomers. I don't believe that and are afraid of the long term developers walking away due to the changes (which is something I saw with every transition). I don't know whether I will continue to contribute if I have to relearn the tooling - my time for KDE is currently very limited. If I have an hour to hack and have to spend half the time on how to contribute now, that sucks and lowers motivation. If you've worked with Github before then Gitlab is very similar, so the learning curve shouldn't be too steep. I haven't worked with github. Changing the tooling will not solve any of the contribution problems. Instead we introduce new ones like all documentation going out of life. Please consider whether the advantages are really worth it. Please also see my comments re. Phabricator upstream as to part of the reason why we're considering this, along with the feedback we received at Akademy last year. Well I remember how phabricator was praised for the very responsive team. That seems to have changed. But who guarantees that gitlab will continue to be responsive and cooperative? Will we have to switch again if the team stops to be responsive? You asked for comments. I gave comment that I'm not pleased about yet another transition. Please keep that in mind. It means learning and interrupted workflows for every one. If you have already decided and don't want anybody to point out that transitions are painful, please don't ask for comments. Instead say that sysadmins decided. That's at least honest - your reply gives me the feeling the decision is already done and negative feedback was not expected. Sorry to feel this way. Cheers Martin
Re: Gitlab Evaluation & Migration
On Monday, 25 February 2019 09:12:47 CET Eike Hein wrote: > On 2/25/19 4:31 AM, Martin Flöser wrote: > > Changing the tooling will not solve any of the contribution problems. > > I'm aware of several projects who would like to incubate with KDE.org > (e.g. Kaidan and Spectral, both new-breed Kirigami apps with new > contributor ecosystems) but are waiting for the outcome of this > decision, because they believe being part of KDE wouldn't be worth the > cost of losing access to contributors that Phabricator imposes to them. > > It's difficult to get hard data on this, of course. From Gnome I've been > told their contributon numbers from new contributors have seen a massive > uptick since adopting GitLab, however their infra pre-GitLab was (to me) > worse than Phabricator. > > It's unclear to me what exactly would happen for us. However, it seems > clear to me that the world outside of the existing cadre of KDE > contribtors has a consensus on this: When the news about the GitLab eval > leaked to Reddit and other venues, "finally I'll be able to submit my > patch" was a recurring theme. > > One thing that strikes me is that KDE upstream relations have usually > been a defining trait of our tooling decisions. We've adopted things > like gitolite, CMake and even Qt based on having an upstream to talk to. > This is currently not the case with Phabricator, but it is the case with > GitLab. I'm hesistant of saying it's awesome just yet (there's some > features in the GitLab Enterprise Edition we would like GitLab to move > to the Community Edition for us, and it's not been decided there yet), > but they've done regular calls with us, opened a master ticket to track > our account with them, and have multiple times expressed an interest in > attending KDE's upcoming Onboarding sprint. This is very nice. > > It's also worth noting that we're the only big FOSS player using > Phabricator at the moment. To contribute to KDE, people have to learn > Phabricator. If they've already contributed to freedesktop, Gnome, or > hundreds of other projects, they've already learned GitLab. > > My personal take is this: I'm used to Phabricator and fine with it. It > doesn't impede my work. But I think it would be a mistake to make this > decision based on what I'm fine with, because I'm equally able to adjust > to GitLab and be fine with that. I'd rather make this decision based on > what people who aren't KDE contributors yet find attractive, and that > seems overwhelmingly in GitLab's favor from everything I've read and > heard. New contributors showing up would affect me a lot more than > having to adjust to typing a different command does. > > I also have reason to believe this delta between "I'm fine with it" and > "Others want X" is only going to increase based on the relative > development speeds of Phabricator and GitLab. The latter seems more > likely to keep up with the state of the art currently. I'd like KDE to > be on board with the state of the art. Heya, +1 on everything Eike said. I think adopting GitLab will be a huge benefit for KDE. Some two-digit million amount of projects hosted on GitLab+GitHub+BitBucket (systems which all share the same "workflow" principles) cannot be wrong. At least there are /tons/ of developers out there which are familiar with them by heart, which makes it super easy for them to contribute to KDE, in theory. Even after having worked a couple of years with Phabricator's review system it stills feels alien to me, mostly b/c it does not integrate that well with Git. I always get slight shivers when having to work with it. I'm contributing to several other projects on either GitLab, GitHub, BitBucket, and the whole experience is simply better. I think there's no doubt about that. The move to yet another system is ambitious but let's rather do it sooner than later. Looking forward to GitLab adoption across the board! Thanks for the effort, guys! Cheers, Kevin > Cheers, > Eike -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Gitlab Evaluation & Migration
Personally I would expect these to be migrated. A switch that doesn't preserve the current task tickets doesn't seem practical to me. Cheers, Eike
Re: Gitlab Evaluation & Migration
On zaterdag 23 februari 2019 12:08:05 CET Boudewijn Rempt wrote: > * 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. Another thing here: what would be a good way to keep the really valuable information we've put in our tasks available? We have been tracking some big projects in phab's task system, and that information would be really hard to lose, but it would also rather suck to have to convert that manually to wiki pages or whatever... -- https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Gitlab Evaluation & Migration
On maandag 25 februari 2019 09:12:47 CET Eike Hein wrote: > > I'm aware of several projects who would like to incubate with KDE.org > (e.g. Kaidan and Spectral, both new-breed Kirigami apps with new > contributor ecosystems) but are waiting for the outcome of this > decision, because they believe being part of KDE wouldn't be worth the > cost of losing access to contributors that Phabricator imposes to them. I've my doubts about that. I haven't had any problems whatsoever attracting new developers to Krita because of phabricator. > It's also worth noting that we're the only big FOSS player using > Phabricator at the moment. Blender uses phabricator, and Blender is a huge FOSS player. Mind, I'm not arguing against moving to gitlab, I guess it's the right thing to do, because Phabricator's lack of maintenance mainly, but let's keep the record straight. -- https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Gitlab Evaluation & Migration
On 2/25/19 4:31 AM, Martin Flöser wrote: Changing the tooling will not solve any of the contribution problems. I'm aware of several projects who would like to incubate with KDE.org (e.g. Kaidan and Spectral, both new-breed Kirigami apps with new contributor ecosystems) but are waiting for the outcome of this decision, because they believe being part of KDE wouldn't be worth the cost of losing access to contributors that Phabricator imposes to them. It's difficult to get hard data on this, of course. From Gnome I've been told their contributon numbers from new contributors have seen a massive uptick since adopting GitLab, however their infra pre-GitLab was (to me) worse than Phabricator. It's unclear to me what exactly would happen for us. However, it seems clear to me that the world outside of the existing cadre of KDE contribtors has a consensus on this: When the news about the GitLab eval leaked to Reddit and other venues, "finally I'll be able to submit my patch" was a recurring theme. One thing that strikes me is that KDE upstream relations have usually been a defining trait of our tooling decisions. We've adopted things like gitolite, CMake and even Qt based on having an upstream to talk to. This is currently not the case with Phabricator, but it is the case with GitLab. I'm hesistant of saying it's awesome just yet (there's some features in the GitLab Enterprise Edition we would like GitLab to move to the Community Edition for us, and it's not been decided there yet), but they've done regular calls with us, opened a master ticket to track our account with them, and have multiple times expressed an interest in attending KDE's upcoming Onboarding sprint. This is very nice. It's also worth noting that we're the only big FOSS player using Phabricator at the moment. To contribute to KDE, people have to learn Phabricator. If they've already contributed to freedesktop, Gnome, or hundreds of other projects, they've already learned GitLab. My personal take is this: I'm used to Phabricator and fine with it. It doesn't impede my work. But I think it would be a mistake to make this decision based on what I'm fine with, because I'm equally able to adjust to GitLab and be fine with that. I'd rather make this decision based on what people who aren't KDE contributors yet find attractive, and that seems overwhelmingly in GitLab's favor from everything I've read and heard. New contributors showing up would affect me a lot more than having to adjust to typing a different command does. I also have reason to believe this delta between "I'm fine with it" and "Others want X" is only going to increase based on the relative development speeds of Phabricator and GitLab. The latter seems more likely to keep up with the state of the art currently. I'd like KDE to be on board with the state of the art. Cheers, Eike
Re: Gitlab Evaluation & Migration
Em 23/02/2019 06:44, Ben Cooksley escreveu: > > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? > It is nice to see this happening, thanks for sysadmin team, onboarding team and all the people involved. For the good or not so good reasons, the repository interfaces github-like are now the standard and it is common to see developers asking to use github because it potentially brings more developers to the project. Gitlab is a way to offer it to now current and potentially new contributors. Just some questions: 1. Do KDE developers need to create accounts in Gitlab instance or a script will do it for us? 2. Will be there any restriction to host projects not related to KDE? Any people can host personal repositories? Including private ones? 3. Will gitlab be a replacement to identity? 4. Is there any date to officially start the migration for all projects? How will it be? Kudos; -- Filipe Saraiva http://filipesaraiva.info/
Re: Gitlab Evaluation & Migration
I use Gitea for my own arm64 server on SoC. In that case it makes sense as it starts quicker and more importantly consumes less memory. So Gitea definitely has its uses. For KDE purposes, I think machine that hosts Gitlab will be more powerful anyway, and it's probably more important that there is always upstream that can respond to our support requests. I guess KDE sysadmins don't want to again end up in "Phabricator" situation where they don't get any support. And regarding using Gitea vs Gitlab, there are more similarities between these two as opposed to Phabricator than differences. There are some things in Gitea that are unsupported in Gitlab and somewhat more vice versa. Andrius 2019 m. vasario 23 d., šeštadienis 21:12:08 GMT Wyatt Childers rašė: > 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 > > > signature.asc Description: This is a digitally signed message part.
Re: Gitlab Evaluation & Migration
On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser wrote: > > Am 2019-02-23 10:44, schrieb Ben Cooksley: > > Hi all, > > > Based on all of the above we'd like to propose migrating towards > > Gitlab. Comments? > > I'm totally honest here: I'm not happy about yet another migration. This > will be the fifth reviewing toolkit I use for KDE (reviewboard for svn, > reviewboard for git, gerrit, phabricator and now gitlab). Each of the > transitions was painful for everyone involved and the commit rate to the > project I was involved suffered from the transitions. As an example for > the problems: KWin's hacking document still mentions reviewboard: > https://community.kde.org/KWin/Hacking#Submitting_Changes Please don't over exaggerate the numbers here. Gerrit was never an official system for reviews, it was something that was evaluated by a small group and which was never proceeded with as an official whole-of-KDE solution. Reviewboard for SVN/Git are basically the same thing (just a different instance url), so this is only really the third system, not the fifth Please also bear in mind that we've been on Git now for coming up on 9 years (I have mails for git.kde.org starting around June 2010) so switching systems twice in that time frame as software continues to mature seems quite reasonable to me. > > I'm not pleased that we want to transit to another solution after just a > few years. I understand that there is the feeling that our phabricator > solution limits contributions from newcomers. I don't believe that and > are afraid of the long term developers walking away due to the changes > (which is something I saw with every transition). I don't know whether I > will continue to contribute if I have to relearn the tooling - my time > for KDE is currently very limited. If I have an hour to hack and have to > spend half the time on how to contribute now, that sucks and lowers > motivation. If you've worked with Github before then Gitlab is very similar, so the learning curve shouldn't be too steep. > > Changing the tooling will not solve any of the contribution problems. > Instead we introduce new ones like all documentation going out of life. > > Please consider whether the advantages are really worth it. Please also see my comments re. Phabricator upstream as to part of the reason why we're considering this, along with the feedback we received at Akademy last year. > > Best regards > Martin Regards, Ben
Re: Gitlab Evaluation & Migration
Am 2019-02-23 10:44, schrieb Ben Cooksley: Hi all, Based on all of the above we'd like to propose migrating towards Gitlab. Comments? I'm totally honest here: I'm not happy about yet another migration. This will be the fifth reviewing toolkit I use for KDE (reviewboard for svn, reviewboard for git, gerrit, phabricator and now gitlab). Each of the transitions was painful for everyone involved and the commit rate to the project I was involved suffered from the transitions. As an example for the problems: KWin's hacking document still mentions reviewboard: https://community.kde.org/KWin/Hacking#Submitting_Changes I'm not pleased that we want to transit to another solution after just a few years. I understand that there is the feeling that our phabricator solution limits contributions from newcomers. I don't believe that and are afraid of the long term developers walking away due to the changes (which is something I saw with every transition). I don't know whether I will continue to contribute if I have to relearn the tooling - my time for KDE is currently very limited. If I have an hour to hack and have to spend half the time on how to contribute now, that sucks and lowers motivation. Changing the tooling will not solve any of the contribution problems. Instead we introduce new ones like all documentation going out of life. Please consider whether the advantages are really worth it. Best regards Martin
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
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
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
сб, 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 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
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 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 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 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 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
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
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
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
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
В Сб, 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
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
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 >
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
