5 ms·

Couldn't see a link in the post but there seems to be an active GitLab instance here[1]. I've only done a few patches with their previous Phabricator flow and i

Couldn't see a link in the post but there seems to be an active GitLab instance here[1]. I've only done a few patches with their previous Phabricator flow and it was a very different experience from the usual GitHub/GitLab workflow. I'm really hoping that switching to something more people have experience with increases the number of contributors. [1]: https://invent.kde.org/public/ https://invent.kde.org/public/

diminish 7y ago
If open source projects adopt continuous integration, release and security scanning it will make outsider to contributions easier to make it into the live.
- lultimouomo 7y ago
  If they were using Phabricator they probably already had a solid sistem of CI and code reviewing.
- that_jojo 7y ago
  In what way? Regardless of whether they're using CI they still have to pull and mainline your change.
  - johannes1234321 7y ago
    It helps to filter out contributions. If CI is broken you send it back to the contributor. Maybe with some guidance. Only if CI passes you take a deeper look. This helps to spend time efficiently. Of course this has the risk that contributors spend much time on making a patch pass all tests and then get it rejected, since maintainers don't like the feature.
    - smudgymcscmudge 7y ago
      It’s also helpful from the other end. As a new contributor, I feel a lot more confident making a PR if there are tests and I can show I didn’t break them.
      - benologist 7y ago
        There are a lot of benefits, like you can have a 'test' that just helps you avoid aggravating scenarios by rejecting pull requests with messy code because the linter failed. If you have to discuss how random pull requests can be improved to meet your standard you are going to waste a lot of energy.
cromka 7y ago
I tried to contribute some simple fixes to kmymoney which I want to move on from GnuCash, but the amount of work required to set everything up, from git cloning to building a dmg package was just too much. I spent like 2 hours with their proprietary build chain and still couldn't obtain a build, so I gave up. Hopefully leveraging GitLab workflow will make things easy.
- ahartmetz 7y ago
  AFAIK there will be no change regarding your problem (a known problem) due to the GitLab transition. But I recommend asking for help on chat (IRC and / or... I think it's Matrix). If you show just a little effort of your own (don't worry, you already did), KDE people tend to be eager to help. Signed, a mostly inactive KDE developer
- EspadaV9 7y ago
  The first time I was trying to build Konsole was a bit painful too, they don't really list what the dependencies are. I ended up creating a docker container based off Fedora 30 and added the packages needed to build the app there, then I can mount my local checking into the container and run `cmake` and `make` there. Not sure how useful that would be if you're trying to build a DMG though.
lima 7y ago
Phabricator is very similar to Gerrit or the LMKL workflow, which - in my opinion - works a lot better for large-scale software development. The first-class CLI (arcanist) is also super helpful - I can easily generate stacked revisions right from my IDE without using a web browser. The issue tracker is also way more powerful than any other open source product. While great for companies who can deal with the onboarding cost, it adds a lot of friction for an open source project so I can see why they move to Gitlab, even if it's less powerful.
- isopede 7y ago
  Can you describe your stacked workflow with phabricator? I have tried to impose the LKML/straight-line-rebase workflow on my teams when I can, but problems with Phabricator _always_ crop up, and it's difficult to onboard people. The default phabricator workflow really likes to squash many commits into a single diff. How do you go about preparing a "stack" of changes, prepare one diff for each git commit, and then apply changes on top of each one as review comments come in? I've ghetto-rigged my own scripts to generate stacked diffs, checking out a new branch for each one, but it's fragile, and not really suitable for sharing with all new team members. I have not found a magic arcanist incantation to generate a changelist based on multiple commits.
  - iggldiggl 7y ago
    > The default phabricator workflow really like to squash many commits into a single diff. That problem also noticeably cropped up when Mozilla switched to Phabricator for its reviews, and the end result was/is that there's now an official helper script for submitting commit stacks without squashing ("moz-phab"). Because that took a little while to develop after Phabricator became mandatory, though (and also because installing arcanist with all its required dependencies can apparently be somewhat of a pain, plus because arcanist has some further foibles like insisting to actually check out each revision you want to submit, which then subsequently can lead to needless recompiling), some people wrote their own solutions, which a) were ready earlier than the official solution and b) allow you to avoid installing arcanist at all: - "Phlay" for Git (https://github.com/mystor/phlay https://github.com/mystor/phlay) - Mercurial already has the "phabsend" extension, which was then forked and extended and currently lives at https://bitbucket.org/KwanEsq/phabsend-moz/src/default/ https://bitbucket.org/KwanEsq/phabsend-moz/src/default/, though I think some changes might have actually made their way back into the original phabsend extension distributed with Mercurial (one problem with the official extensions as of a while ago was that it used a Phabricator API that didn't work for binary files - I think this has been fixed in the fork, but not yet in the official extension included directly with Mercurial). (Also I think that there's currently work underway to make "moz-phab" work without a local arcanist installation, too). So the takeaway from this is that there is indeed no good official solution for this, but "phabsend" or "phlay" might be a better starting point.

diminish 7y ago

If open source projects adopt continuous integration, release and security scanning it will make outsider to contributions easier to make it into the live.

lultimouomo 7y ago
If they were using Phabricator they probably already had a solid sistem of CI and code reviewing.
that_jojo 7y ago
In what way? Regardless of whether they're using CI they still have to pull and mainline your change.
- johannes1234321 7y ago
  It helps to filter out contributions. If CI is broken you send it back to the contributor. Maybe with some guidance. Only if CI passes you take a deeper look. This helps to spend time efficiently. Of course this has the risk that contributors spend much time on making a patch pass all tests and then get it rejected, since maintainers don't like the feature.
  - smudgymcscmudge 7y ago
    It’s also helpful from the other end. As a new contributor, I feel a lot more confident making a PR if there are tests and I can show I didn’t break them.
    - benologist 7y ago
      There are a lot of benefits, like you can have a 'test' that just helps you avoid aggravating scenarios by rejecting pull requests with messy code because the linter failed. If you have to discuss how random pull requests can be improved to meet your standard you are going to waste a lot of energy.

cromka 7y ago

I tried to contribute some simple fixes to kmymoney which I want to move on from GnuCash, but the amount of work required to set everything up, from git cloning to building a dmg package was just too much. I spent like 2 hours with their proprietary build chain and still couldn't obtain a build, so I gave up. Hopefully leveraging GitLab workflow will make things easy.

ahartmetz 7y ago
AFAIK there will be no change regarding your problem (a known problem) due to the GitLab transition. But I recommend asking for help on chat (IRC and / or... I think it's Matrix). If you show just a little effort of your own (don't worry, you already did), KDE people tend to be eager to help. Signed, a mostly inactive KDE developer
EspadaV9 7y ago
The first time I was trying to build Konsole was a bit painful too, they don't really list what the dependencies are. I ended up creating a docker container based off Fedora 30 and added the packages needed to build the app there, then I can mount my local checking into the container and run `cmake` and `make` there. Not sure how useful that would be if you're trying to build a DMG though.

lima 7y ago

Phabricator is very similar to Gerrit or the LMKL workflow, which - in my opinion - works a lot better for large-scale software development. The first-class CLI (arcanist) is also super helpful - I can easily generate stacked revisions right from my IDE without using a web browser. The issue tracker is also way more powerful than any other open source product. While great for companies who can deal with the onboarding cost, it adds a lot of friction for an open source project so I can see why they move to Gitlab, even if it's less powerful.

isopede 7y ago
Can you describe your stacked workflow with phabricator? I have tried to impose the LKML/straight-line-rebase workflow on my teams when I can, but problems with Phabricator _always_ crop up, and it's difficult to onboard people. The default phabricator workflow really likes to squash many commits into a single diff. How do you go about preparing a "stack" of changes, prepare one diff for each git commit, and then apply changes on top of each one as review comments come in? I've ghetto-rigged my own scripts to generate stacked diffs, checking out a new branch for each one, but it's fragile, and not really suitable for sharing with all new team members. I have not found a magic arcanist incantation to generate a changelist based on multiple commits.
- iggldiggl 7y ago
  > The default phabricator workflow really like to squash many commits into a single diff. That problem also noticeably cropped up when Mozilla switched to Phabricator for its reviews, and the end result was/is that there's now an official helper script for submitting commit stacks without squashing ("moz-phab"). Because that took a little while to develop after Phabricator became mandatory, though (and also because installing arcanist with all its required dependencies can apparently be somewhat of a pain, plus because arcanist has some further foibles like insisting to actually check out each revision you want to submit, which then subsequently can lead to needless recompiling), some people wrote their own solutions, which a) were ready earlier than the official solution and b) allow you to avoid installing arcanist at all: - "Phlay" for Git (https://github.com/mystor/phlay https://github.com/mystor/phlay) - Mercurial already has the "phabsend" extension, which was then forked and extended and currently lives at https://bitbucket.org/KwanEsq/phabsend-moz/src/default/ https://bitbucket.org/KwanEsq/phabsend-moz/src/default/, though I think some changes might have actually made their way back into the original phabsend extension distributed with Mercurial (one problem with the official extensions as of a while ago was that it used a Phabricator API that didn't work for binary files - I think this has been fixed in the fork, but not yet in the official extension included directly with Mercurial). (Also I think that there's currently work underway to make "moz-phab" work without a local arcanist installation, too). So the takeaway from this is that there is indeed no good official solution for this, but "phabsend" or "phlay" might be a better starting point.