Re: Concluding the Gitlab Discussion
On Tue, Mar 19, 2019 at 9:26 PM Ben Cooksley wrote: > > Hi all, > > Over the past few weeks we've had a discussion on whether we'd like to > migrate from Phabricator to Gitlab, for handling both our code reviews > as well as internal tasks (user facing bug reports are explicitly out > of context at this time) > > Based on the comments the overall consensus seems to be at this stage > to favour switching to Gitlab. > > This however is subject to a caveat around multiple task boards, which > would be needed for larger projects to effectively coordinate amongst > the various sub-projects. > > As part of the transition we will also arrange for the email interface > to be enabled (for emailing in patches) and for the default for merges > to be rebase when it's not a fast forward merge for all repositories. > > Does anyone have any final comments? > > In terms of the steps forward from here, Sysadmin will need a bit of > time to prepare various parts of the infrastructure for the transition > (such as the anongit network, which will need a full rebuild as part > of switching). > > Once this is complete, we'll be in touch with more information on how > the transition will take place. As it has now been a month since the initial thread was opened, and with no final comments aside from Nate's over the past couple of days, it seems that everyone is happy with the above as the community consensus. We'll now proceed with preparing for a migration to Gitlab, subject to the above caveat of getting multi-project boards (and with a request to see if we can get merge request approvers sorted as well if possible) > > Thanks, > Ben Cooksley > KDE Sysadmin Regards, Ben
Re: Concluding the Gitlab Discussion
On Tue, Mar 19, 2019 at 10:47 PM Nate Graham wrote: > > One thing I'd really like to not lose is the review status feature > (approved/changes requested/etc). I've head that this is EE only. Is there > any word on getting that added to our package? We'll look into discussing this with them. > > Other than that, I think I think what Gitlab offers over Phabricator is > either a significant win or else just something different that you can get > used to quickly. > > Nate Regards, Ben > > > On Tue, 19 Mar 2019 02:26:24 -0600 Ben Cooksley > wrote > > Hi all, > > > > Over the past few weeks we've had a discussion on whether we'd like to > > migrate from Phabricator to Gitlab, for handling both our code reviews > > as well as internal tasks (user facing bug reports are explicitly out > > of context at this time) > > > > Based on the comments the overall consensus seems to be at this stage > > to favour switching to Gitlab. > > > > This however is subject to a caveat around multiple task boards, which > > would be needed for larger projects to effectively coordinate amongst > > the various sub-projects. > > > > As part of the transition we will also arrange for the email interface > > to be enabled (for emailing in patches) and for the default for merges > > to be rebase when it's not a fast forward merge for all repositories. > > > > Does anyone have any final comments? > > > > In terms of the steps forward from here, Sysadmin will need a bit of > > time to prepare various parts of the infrastructure for the transition > > (such as the anongit network, which will need a full rebuild as part > > of switching). > > > > Once this is complete, we'll be in touch with more information on how > > the transition will take place. > > > > Thanks, > > Ben Cooksley > > KDE Sysadmin > > >
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: lgtm integration (automated detection of bugs and problems for programming languages)
On Fri, Mar 22, 2019 at 2:45 PM alcinos wrote: > > > > Le ven. 22 mars 2019 à 14:40, Tomaz Canabrava a écrit : >> >> On Fri, Mar 22, 2019 at 2:31 PM alcinos wrote: >> > >> > Is there a way to somehow configure the build process? Their automatic >> > dependency pulling is getting an outdated version of Melt, and it breaks >> > the build for us in Kdenlive... >> >> Yes, you can define a yaml file for it in the root dir, like krita did here: >> https://github.com/KDE/krita/blob/master/.lgtm.yml > > > It seems that they only give a package list? I don't think it would help in > our case, the root cause of the issue being that the Mlt package is outdated > in the repo of whatever distrib they use to build... true, but we can get in contact with them to resolve. I'm opening a request for that. > >> >> > Le ven. 22 mars 2019 à 07:43, Tomaz Canabrava a écrit >> > : >> >> >> >> On Thu, Mar 21, 2019 at 9:27 PM Albert Astals Cid wrote: >> >> > >> >> > El dijous, 21 de març de 2019, a les 20:31:34 CET, Tomaz Canabrava va >> >> > escriure: >> >> > > Em qui, 21 de mar de 2019 às 19:48, Albert Astals Cid >> >> > > escreveu: >> >> > > >> >> > > > El dijous, 21 de març de 2019, a les 10:04:29 CET, Tomaz Canabrava >> >> > > > va >> >> > > > escriure: >> >> > > > > Hello kdevelopers, >> >> > > > > >> >> > > > > I'v come to know the lgtm.com this week and started to enjoy it >> >> > > > > quite >> >> > > > > a bit. It provides code analisys for various languages like c/c++ >> >> > > > > / >> >> > > > > java / javascript / python, transforming code to data and >> >> > > > > extracting >> >> > > > > information using a QL Schema + Deep learning. >> >> > > > > >> >> > > > > It's opensource >> >> > > > >> >> > > > Is it? I can't seem to find the code. >> >> > > > >> >> > > > > , and *already* runs thru all the kde codebase because >> >> > > > > our code has a mirror on github (but it also supports gitlab, >> >> > > > > bitbucket). Some of the code from kde can't be analized yet >> >> > > > > because of >> >> > > > > unmatched dependencies, but here's an example of a software we all >> >> > > > > know and love, being analized by their tools. >> >> > > > > >> >> > > > > https://lgtm.com/projects/g/KDAB/GammaRay/alerts/?mode=list >> >> > > > > >> >> > > > > I belive we should get in contact with them and ask for a ~formal~ >> >> > > > > partnership and integrate this into our phab / gitlab instances. >> >> > > > >> >> > > > I'm a bit hesitant about it's quality. >> >> > > > >> >> > > > It complains about >> >> > > > https://lgtm.com/projects/g/KDAB/GammaRay/snapshot/c9979de8f1206e13596392237af218cd35adc139/files/plugins/sceneinspector/paintanalyzerextension.cpp#x6a2cbfa5e54b631a:1 >> >> > > > If you read the description it'd seem it's a memory leak. >> >> > > > That's because it doesn't understand QObject ownership and >> >> > > > that >> >> > > > deleting a parent will delete its children. >> >> > > > >> >> > > > It says this is an error >> >> > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/core/synctex/synctex_parser_utils.c#x6d7e052c9ef1e80:1 >> >> > > > It's not, i'll agree it's not very common to do this >> >> > > > comparison, >> >> > > > but it's valid code >> >> > > > >> >> > > > It says this is a noop >> >> > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/autotests/parttest.cpp?sort=name&dir=ASC&mode=heatmap#x9525a92bb944ee97:1 >> >> > > > It's not, qRegisterMetaType does things >> >> > > > >> >> > > > So I'm happy that those results are out there, but given the amount >> >> > > > of >> >> > > > false/questionable positives i found in 5 minutes of looking at it, >> >> > > > I'd be >> >> > > > very careful of giving it to "the general population", that may just >> >> > > > propose changes because a tool told them to. >> >> > > > >> >> > > > Cheers, >> >> > > > Albert >> >> > > > >> >> > > >> >> > > They are already working in two of the bugs that you described - >> >> > > reported >> >> > > by the subsurface team. >> >> > > >> >> > > The source for parts of the tools are here: >> >> > > >> >> > > https://github.com/Semmle/ql >> >> > > >> >> > > And of course as any tool that is starting there will be errors. >> >> > >> >> > Sure, i never said it's useless, in fact it did find some mismatched >> >> > free/delete/delete[] calls in both okular and poppler. >> >> > >> >> > I just want to make sure we don't tell people "these are bugs, go fix >> >> > them", because then people will take the tool at 100% correct rate >> >> > value, when it's not that kind of tool. >> >> >> >> I opened bug reports to them: >> >> >> >> https://github.com/Semmle/ql/issues/1153 >> >> this one I'm not convinced yet. >> >> >> >> https://github.com/Semmle/ql/issues/1154 >> >> this one it seems that it was not false positive. >> >> >> >> :) >> >> >> >> > Cheers, >> >> > Albert >> >> > >> >>
Re: lgtm integration (automated detection of bugs and problems for programming languages)
Le ven. 22 mars 2019 à 14:40, Tomaz Canabrava a écrit : > On Fri, Mar 22, 2019 at 2:31 PM alcinos > wrote: > > > > Is there a way to somehow configure the build process? Their automatic > dependency pulling is getting an outdated version of Melt, and it breaks > the build for us in Kdenlive... > > Yes, you can define a yaml file for it in the root dir, like krita did > here: > https://github.com/KDE/krita/blob/master/.lgtm.yml It seems that they only give a package list? I don't think it would help in our case, the root cause of the issue being that the Mlt package is outdated in the repo of whatever distrib they use to build... > > Le ven. 22 mars 2019 à 07:43, Tomaz Canabrava a > écrit : > >> > >> On Thu, Mar 21, 2019 at 9:27 PM Albert Astals Cid > wrote: > >> > > >> > El dijous, 21 de març de 2019, a les 20:31:34 CET, Tomaz Canabrava va > escriure: > >> > > Em qui, 21 de mar de 2019 às 19:48, Albert Astals Cid < > aa...@kde.org> > >> > > escreveu: > >> > > > >> > > > El dijous, 21 de març de 2019, a les 10:04:29 CET, Tomaz > Canabrava va > >> > > > escriure: > >> > > > > Hello kdevelopers, > >> > > > > > >> > > > > I'v come to know the lgtm.com this week and started to enjoy > it quite > >> > > > > a bit. It provides code analisys for various languages like > c/c++ / > >> > > > > java / javascript / python, transforming code to data and > extracting > >> > > > > information using a QL Schema + Deep learning. > >> > > > > > >> > > > > It's opensource > >> > > > > >> > > > Is it? I can't seem to find the code. > >> > > > > >> > > > > , and *already* runs thru all the kde codebase because > >> > > > > our code has a mirror on github (but it also supports gitlab, > >> > > > > bitbucket). Some of the code from kde can't be analized yet > because of > >> > > > > unmatched dependencies, but here's an example of a software we > all > >> > > > > know and love, being analized by their tools. > >> > > > > > >> > > > > https://lgtm.com/projects/g/KDAB/GammaRay/alerts/?mode=list > >> > > > > > >> > > > > I belive we should get in contact with them and ask for a > ~formal~ > >> > > > > partnership and integrate this into our phab / gitlab instances. > >> > > > > >> > > > I'm a bit hesitant about it's quality. > >> > > > > >> > > > It complains about > >> > > > > https://lgtm.com/projects/g/KDAB/GammaRay/snapshot/c9979de8f1206e13596392237af218cd35adc139/files/plugins/sceneinspector/paintanalyzerextension.cpp#x6a2cbfa5e54b631a:1 > >> > > > If you read the description it'd seem it's a memory leak. > >> > > > That's because it doesn't understand QObject ownership > and that > >> > > > deleting a parent will delete its children. > >> > > > > >> > > > It says this is an error > >> > > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/core/synctex/synctex_parser_utils.c#x6d7e052c9ef1e80:1 > >> > > > It's not, i'll agree it's not very common to do this > comparison, > >> > > > but it's valid code > >> > > > > >> > > > It says this is a noop > >> > > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/autotests/parttest.cpp?sort=name&dir=ASC&mode=heatmap#x9525a92bb944ee97:1 > >> > > > It's not, qRegisterMetaType does things > >> > > > > >> > > > So I'm happy that those results are out there, but given the > amount of > >> > > > false/questionable positives i found in 5 minutes of looking at > it, I'd be > >> > > > very careful of giving it to "the general population", that may > just > >> > > > propose changes because a tool told them to. > >> > > > > >> > > > Cheers, > >> > > > Albert > >> > > > > >> > > > >> > > They are already working in two of the bugs that you described - > reported > >> > > by the subsurface team. > >> > > > >> > > The source for parts of the tools are here: > >> > > > >> > > https://github.com/Semmle/ql > >> > > > >> > > And of course as any tool that is starting there will be errors. > >> > > >> > Sure, i never said it's useless, in fact it did find some mismatched > free/delete/delete[] calls in both okular and poppler. > >> > > >> > I just want to make sure we don't tell people "these are bugs, go fix > them", because then people will take the tool at 100% correct rate value, > when it's not that kind of tool. > >> > >> I opened bug reports to them: > >> > >> https://github.com/Semmle/ql/issues/1153 > >> this one I'm not convinced yet. > >> > >> https://github.com/Semmle/ql/issues/1154 > >> this one it seems that it was not false positive. > >> > >> :) > >> > >> > Cheers, > >> > Albert > >> > > >> > > > >> > > > >> > > > > >> > > > > > >> > > > > Tomaz > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > > >> > > >> > >
Re: lgtm integration (automated detection of bugs and problems for programming languages)
On Fri, Mar 22, 2019 at 2:31 PM alcinos wrote: > > Is there a way to somehow configure the build process? Their automatic > dependency pulling is getting an outdated version of Melt, and it breaks the > build for us in Kdenlive... Yes, you can define a yaml file for it in the root dir, like krita did here: https://github.com/KDE/krita/blob/master/.lgtm.yml (but krita took so long to build there that they timed it out :( > Le ven. 22 mars 2019 à 07:43, Tomaz Canabrava a écrit : >> >> On Thu, Mar 21, 2019 at 9:27 PM Albert Astals Cid wrote: >> > >> > El dijous, 21 de març de 2019, a les 20:31:34 CET, Tomaz Canabrava va >> > escriure: >> > > Em qui, 21 de mar de 2019 às 19:48, Albert Astals Cid >> > > escreveu: >> > > >> > > > El dijous, 21 de març de 2019, a les 10:04:29 CET, Tomaz Canabrava va >> > > > escriure: >> > > > > Hello kdevelopers, >> > > > > >> > > > > I'v come to know the lgtm.com this week and started to enjoy it quite >> > > > > a bit. It provides code analisys for various languages like c/c++ / >> > > > > java / javascript / python, transforming code to data and extracting >> > > > > information using a QL Schema + Deep learning. >> > > > > >> > > > > It's opensource >> > > > >> > > > Is it? I can't seem to find the code. >> > > > >> > > > > , and *already* runs thru all the kde codebase because >> > > > > our code has a mirror on github (but it also supports gitlab, >> > > > > bitbucket). Some of the code from kde can't be analized yet because >> > > > > of >> > > > > unmatched dependencies, but here's an example of a software we all >> > > > > know and love, being analized by their tools. >> > > > > >> > > > > https://lgtm.com/projects/g/KDAB/GammaRay/alerts/?mode=list >> > > > > >> > > > > I belive we should get in contact with them and ask for a ~formal~ >> > > > > partnership and integrate this into our phab / gitlab instances. >> > > > >> > > > I'm a bit hesitant about it's quality. >> > > > >> > > > It complains about >> > > > https://lgtm.com/projects/g/KDAB/GammaRay/snapshot/c9979de8f1206e13596392237af218cd35adc139/files/plugins/sceneinspector/paintanalyzerextension.cpp#x6a2cbfa5e54b631a:1 >> > > > If you read the description it'd seem it's a memory leak. >> > > > That's because it doesn't understand QObject ownership and that >> > > > deleting a parent will delete its children. >> > > > >> > > > It says this is an error >> > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/core/synctex/synctex_parser_utils.c#x6d7e052c9ef1e80:1 >> > > > It's not, i'll agree it's not very common to do this >> > > > comparison, >> > > > but it's valid code >> > > > >> > > > It says this is a noop >> > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/autotests/parttest.cpp?sort=name&dir=ASC&mode=heatmap#x9525a92bb944ee97:1 >> > > > It's not, qRegisterMetaType does things >> > > > >> > > > So I'm happy that those results are out there, but given the amount of >> > > > false/questionable positives i found in 5 minutes of looking at it, >> > > > I'd be >> > > > very careful of giving it to "the general population", that may just >> > > > propose changes because a tool told them to. >> > > > >> > > > Cheers, >> > > > Albert >> > > > >> > > >> > > They are already working in two of the bugs that you described - reported >> > > by the subsurface team. >> > > >> > > The source for parts of the tools are here: >> > > >> > > https://github.com/Semmle/ql >> > > >> > > And of course as any tool that is starting there will be errors. >> > >> > Sure, i never said it's useless, in fact it did find some mismatched >> > free/delete/delete[] calls in both okular and poppler. >> > >> > I just want to make sure we don't tell people "these are bugs, go fix >> > them", because then people will take the tool at 100% correct rate value, >> > when it's not that kind of tool. >> >> I opened bug reports to them: >> >> https://github.com/Semmle/ql/issues/1153 >> this one I'm not convinced yet. >> >> https://github.com/Semmle/ql/issues/1154 >> this one it seems that it was not false positive. >> >> :) >> >> > Cheers, >> > Albert >> > >> > > >> > > >> > > > >> > > > > >> > > > > Tomaz >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > >> > >> > >> >
Re: lgtm integration (automated detection of bugs and problems for programming languages)
Is there a way to somehow configure the build process? Their automatic dependency pulling is getting an outdated version of Melt, and it breaks the build for us in Kdenlive... Le ven. 22 mars 2019 à 07:43, Tomaz Canabrava a écrit : > On Thu, Mar 21, 2019 at 9:27 PM Albert Astals Cid wrote: > > > > El dijous, 21 de març de 2019, a les 20:31:34 CET, Tomaz Canabrava va > escriure: > > > Em qui, 21 de mar de 2019 às 19:48, Albert Astals Cid > > > escreveu: > > > > > > > El dijous, 21 de març de 2019, a les 10:04:29 CET, Tomaz Canabrava va > > > > escriure: > > > > > Hello kdevelopers, > > > > > > > > > > I'v come to know the lgtm.com this week and started to enjoy it > quite > > > > > a bit. It provides code analisys for various languages like c/c++ / > > > > > java / javascript / python, transforming code to data and > extracting > > > > > information using a QL Schema + Deep learning. > > > > > > > > > > It's opensource > > > > > > > > Is it? I can't seem to find the code. > > > > > > > > > , and *already* runs thru all the kde codebase because > > > > > our code has a mirror on github (but it also supports gitlab, > > > > > bitbucket). Some of the code from kde can't be analized yet > because of > > > > > unmatched dependencies, but here's an example of a software we all > > > > > know and love, being analized by their tools. > > > > > > > > > > https://lgtm.com/projects/g/KDAB/GammaRay/alerts/?mode=list > > > > > > > > > > I belive we should get in contact with them and ask for a ~formal~ > > > > > partnership and integrate this into our phab / gitlab instances. > > > > > > > > I'm a bit hesitant about it's quality. > > > > > > > > It complains about > > > > > https://lgtm.com/projects/g/KDAB/GammaRay/snapshot/c9979de8f1206e13596392237af218cd35adc139/files/plugins/sceneinspector/paintanalyzerextension.cpp#x6a2cbfa5e54b631a:1 > > > > If you read the description it'd seem it's a memory leak. > > > > That's because it doesn't understand QObject ownership and > that > > > > deleting a parent will delete its children. > > > > > > > > It says this is an error > > > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/core/synctex/synctex_parser_utils.c#x6d7e052c9ef1e80:1 > > > > It's not, i'll agree it's not very common to do this > comparison, > > > > but it's valid code > > > > > > > > It says this is a noop > > > > > https://lgtm.com/projects/g/KDE/okular/snapshot/9755abc39706567915f1d1b757b70e2a0f8e3f3a/files/autotests/parttest.cpp?sort=name&dir=ASC&mode=heatmap#x9525a92bb944ee97:1 > > > > It's not, qRegisterMetaType does things > > > > > > > > So I'm happy that those results are out there, but given the amount > of > > > > false/questionable positives i found in 5 minutes of looking at it, > I'd be > > > > very careful of giving it to "the general population", that may just > > > > propose changes because a tool told them to. > > > > > > > > Cheers, > > > > Albert > > > > > > > > > > They are already working in two of the bugs that you described - > reported > > > by the subsurface team. > > > > > > The source for parts of the tools are here: > > > > > > https://github.com/Semmle/ql > > > > > > And of course as any tool that is starting there will be errors. > > > > Sure, i never said it's useless, in fact it did find some mismatched > free/delete/delete[] calls in both okular and poppler. > > > > I just want to make sure we don't tell people "these are bugs, go fix > them", because then people will take the tool at 100% correct rate value, > when it's not that kind of tool. > > I opened bug reports to them: > > https://github.com/Semmle/ql/issues/1153 > this one I'm not convinced yet. > > https://github.com/Semmle/ql/issues/1154 > this one it seems that it was not false positive. > > :) > > > Cheers, > > Albert > > > > > > > > > > > > > > > > > > > > > > Tomaz > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
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.
