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.
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.
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.
> 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:
- Mercurial already has the "phabsend" extension, which was then forked and extended and currently lives at 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.
I really want to wanted to like Phabricator, but every interaction with arcanist just feels like hitting the "I'm feeling lucky" button. It completely violates the principle of least surprise. To me, at least.
My new team is using Github. Can Github be wrangled to enforce a rebase-on-merge workflow with PRs? I am committed to keeping the "one commit per idea" mantra, but I don't see any way in Github to enforce "no-merge commits."
Does Github keep track of comments across PRs if they are rebased? I don't want to see extra commits on top of PRs that consist of things like "address reviewer A's comments," but I do want the comments tracked on Github. Is this possible?
What you want to do is to submit one revision per commit, and link them together via dependencies (the experimental branch of arcanist does this automatically). Having individual revisions is one of the main advantages of this workflow.
You then set your .arcrc base to git:HEAD^ and have one local branch per stack, submitting each via arc diff. There a 1:1 mapping between revisions and commits, which makes things a LOT easier, especially rebases. You can then use an interactive rebase to re-visit and amend old revisions, or land them.
I also have an autodiff alias in .arcrc that will automatically create a new revision and open it in the browser, assuming the Test Plan field is already filled out in the commit:
And useful .bashrc aliases for working with a stack:
alias cascade-show="git log @{push}..HEAD --oneline"
alias cascade-amend="git rebase @{push} -x 'arc amend'"
alias cascade-rebase="git rebase -i @{push}"
alias cascade-autorebase="git rebase -i @{push} -x 'arc diff HEAD^ -m Autorebase'"
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.
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.
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.
If open source projects adopt continuous integration, release and security scanning it will make outsider to contributions easier to make it into the live.
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.
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.
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.
Markdown is already rendered in the repo and can live next to the code. Meaning that merge requests can update both the code and documentation at the same time. And GitLab / GitHub have embedded editors that allow you to edit the markdown files using from the browser, just like a wiki.
Basically the only thing that is left is that the wiki can be edited without supervision.
My company uses GitLab/Jira/Confluence, and two super-important features that make Confluence a winner in my mind are a) a way better story for media embedding (including photos and random uploads like PDFs, but also rich/interactive media such as LucidChart and rendering ticket lists from a Jira filter), and b) the inline discussion/annotation framework that lets you tag/nag people, ask for clarification, etc. A big part of inline discussion is that it's an instant marker for later readers that the content may not be up to date or is under discussion/review, whereas a Markdown file in some repo can have a ticket filed against it, but there's nothing in the repo that alerts a later reader to the existence of that ticket until the problem is actually resolved.
I've always been an advocate for the "markdown in the repo" scheme with CI-generated Sphinx (or whatever) docs, but these features have really won me over to the standalone wiki at least in some cases.
Non-programmers are more comfortable in the Wiki. And it's probably safer to keep them there anyway, and edits can be allowed there with fewer safeguards.
Then again I'm not sure how many non-technical folks are willing to dig into GH anyway. I've heard Issues & friends called "too confusing" for "non-technical" folks, in favor of Asana and Jira, of all things. Huge WTF from me since I'd say the opposite is strongly true regardless how "technical" one is, but that's the perception I guess.
I find they're rarely good, but I can see that having them live alongside code is good sometimes (as you say) but not so great when it needs to be changed independent of the code around it and you have a load 'fix markdown rendering' or 'fix typo' commits.
That feels like a failure of the tool/workflow— when you use the web UI edit button, it should put your edits on a branch for review, and make it easy to make further edits/corrections and then squash all of the piddly fixes into one big change at the end.
Fortunately, you can disable the wiki (and snippets!) on a per-project basis in at least Gitlab. Which is what we do on all our projects to ensure that everything goes through a single versioning flow.
Gitlab is not just git hosting, they want to own the full developing cycle. they already got ci pipelines, easy ways to deploy on kubernates, and much more and its feature are growing at a fast. You cannnot replicate every gitlab feature with 10M, and you still have to fight the network effect.
For years Gitlab had a better offer then Github, and yet github was always more popular due to the network effect.
That's not how it works.
Open source makes it trivial for the nerds inside a company to deploy. Soon, they start taking advantage of various APIs and integrations. They'll have scripts written in Bash, Perl, Python, Ruby and what not talking to various API endpoints, communicating with other systems using JSON, XML, etc. Every single bot or integration like that is one more "tentacle".
Without signing a contract or even having the board or upper management discuss it, the organization is now entrenched with this piece of software. Comes along a new regulation for your industry; GPDR, SOX, HIPAA, etc. It doesn't matter. What do you do? Fortunately, the provider of your "open source" (or rather: open core) solution offers features supporting your use case. You just have to upgrade from the MIT-licensed core, community edition to the enterprise edition, for $xx,xxx per year.
Nobody cares about that. Sales and value is what matters in the real-world. Gitlab has sales from customers who have proven they value the product. That's where the valuation comes from.
It doesn't matter if you can clone it exactly tomorrow. Go ahead and do so. It won't give you the same valuation and it won't hurt theirs because that's not how it works.
Right. And next you’re going to tell me that the majority of their users don’t just download the software and deploy it without paying.
Gitlab as a company is about a precarious as Docker as a company. Most of its users are using it for free, and the few that are paying would happily pay anyone else who provided support for the same software. It’s a commodity.
All freemium business models have a large free usage tier. This is completely unsurprising.
But yes, many people also pay Gitlab for enterprise features (which are not open-source), hosting, support, and more. If they would pay anyone else then why aren't they using Github? If they just wanted git itself then why aren't they using the numerous lightweight alternatives?
Business isn't as simple as replicating a product, it's about selling value, and Gitlab has a unique solution that covers the entire software lifecycle. I'm sure you know all this but yet you've made numerous posts disparaging this company. Why, exactly?
I love how the gitlab fanboys try to have it both ways.
When arguing why it’s better than alternatives, the talking point is that “it’s open-source!” But when it’s (rightfully) pointed out that this doesn’t leave much of a defensive moat, the open-source philosophy gets thrown under the bus.
Yes, yes...it’s “open core”. That just means that it’s 10% more difficult to clone and replicate the business. Mark my words: someday, Gitlab will do something to piss off the “community”, and this will quickly happen.
Gitea is already a decent competitor, valued at $0.
What gives a company like this value are the contracts and the technical lock-ins making sure you can milk a relatively small group of captive, high-value users for many years. There are many companies using Gitlab.
Building a product is the easy part. Building the user base is what makes an evaluation. Just the same as anyone can start a fast food chain but if no buys any food in there the chain isn’t worth squat.
When our firm moved to git, Github and Gitlab were chosen as options and since gitlab gave us a better offer, we took it. However, the firm also uses Jira and now we are getting a better offer with Jira, Confluence and bitbucket. Eventhough Gitlab is loved by our team, It looks like Bitbucket will be the future for us. So you should not underestimate the market presence of a company.
It is a mistake to let the issue tracker (Jira) drive tool selection instead of the developer tools (configuration management, continuous integration). Be cautious of the switch if your company is switching for that reason.
The problem is that we are a team of 12 use the versioning, while more than 500 people of various teams use Jira and Atlassian toolset ( Whose jobs dont require versioning, as we create tools that hide/simplify the process for them).
Because Atlassian manages to extract boatloads of enterprise money for a product portfolio that can be best described as an inconsistent, unintegrated mess.
Everything they have was bought together and crudely integrated, with each product having totally different ways of using and administrating them. Not to mention that core features (e.g. "merging" duplicate user accounts, SAML login) are paid-for plugins of varying quality. Feature suggestions for the products end up in multi-year-old tickets that one has no way to influence.
But still, enterprises are buying up that crap because the alternatives to JIRA and Confluence plainly suck even more. The only thing that has real competition is Bitbucket, with Gitlab and Github as more than viable alternatives.
Atlassian have very successfully aligned themselves with the managerial layer that like to think their organisations are "agile", or believe that buying some software suite will somehow bring that about, rather than simply codify and entrench their existing faulty workflows and add new processes to bureaucratize.
Agile equals a bunch of complicated "workflows" in Jira. This is a real thing that a non-small number of managers believe. Or if they don't believe it, they sure act like they do.
This came up on the Hadoop JIRA lately. Someone submitted an issue several years ago and the team is investigating it now and he was trying to figure out how to get off the notification list. They ended up having to change the reporter. jfc jira's a mess.
Extracting money is what a business does. They managed to extract enough to get their valuation. It has nothing to do with how bad the product is, and shows why sales is far more important than tech when building a company.
There are bug trackers that have more features compared to Github/Gitlab.
> Merge requests that are easy to analyze
You can get that through pure git by using git format-patch and git send-email
> Ability to put comments during a code review on specific lines of code and discuss it from there
You can get that by replying inline to the email containing the patch (much like I'm doing here when replying to a certain part of your comment).
> Embedded wiki for a project
That could be maintained in the docs directory of the project
> Managing different access rights to different repos
Given that the project maintainer(s) maintain access to their repos, they could just as well handle the access rights without having to rely on Github/Gitlab.
I'm a happy GitHub user, these things I'd miss from pure git:
- Search (across code, issues, pull requests etc)
- Issue tracker (~ manage my backlog, write down potential ideas)
- Pull requests, review UI around them
- GitHub Apps and Actions (~ automation) and integration with third-party tools (auto-deploy changes to zeit.co / netlify / heroku etc).
- Security audits (GitHub can send pull requests to bump my dependencies when security vulns are discovered in them)
- Ability to contribute without having to fork/clone/push changes (I quite often contribute to projects by editing the code directly through the GitHub website).
> (I quite often contribute to projects by editing the code directly through the GitHub website)
Whenever I do that I get as far as the commit message and, lacking vi and a 72 char marker, commit 'wip', pull down the changes, amend the commit, and wish I'd done the whole thing locally faster and more easily in the first place.
I've never the GitHub editor/UI to submit non-trivial changes which require more than a few words to describe. I do not need vi to write "Fix a typo in the documentation".
Is it you or the project owners who care about the 72 character limit? IME most projects will accept contributions regardless of formatting of the commit message. Most people are just happy about contributions, regardless of source.
For me, using pure git is fine when working on solo projects. The benefits of such services is when there are many developers in the same project. Gives a good overview of issue reports, what commits are linked to what issues, easy "pull request" overviews/quick reviews without checking out branches etc. It's more about the social and less about the source control for me
Continuous Integration. Don't understand how anyone wants to run a software project without an independent and automatic test-runner.
For Github this means using Travis CI, CircleCI, Appveyor etc
Sure you do. Lots of projects are using compiled languages, even if the developers for whatever reason have decided to not write tests (lazy? lack of competence? decided tests wont benfit the project).
These projects too will benefit from a independent CI-service validating their commits.
You don't really need gitlab/github for that, you can automate any kind of tests/build/deployment process with pure git hooks.
I personally feel gitlab/github are useful from community and collaboration aspects - there is nothing I couldn't do without github on my solo projects from purely technical point of view, it's strengths are issue tracking, pull requests, wikis, distribution of code.
For my personal projects I use Gitea (source code hosting) + Bazel (build system) + Drone.io (automated builds) + Harbor (container registry) + Keel (deployment to Kubernetes). At a glance of Gitlab's documentation it looks like these tools cover most of what GitLab CI/Registry does, is there anything major I'm missing that you'd describe as a killer feature?
Sorry for the late response. The killer feature of GitLabCI is that it offers the same functionality as all the tools you've mentioned but much better integrated because they are all part of GitLab. E.g. for CI you don't need to configure webhooks to trigger a build, you just assign a runner to the project and add a .gitlabci.yml.
Source control is really only the 'hook' that brings developers into both GitHub and GitLab.
Primarily they're communities which grow in value based on the number of developers and projects hosted within them.
Some of the powerful resulting centralized features are:
* The social / team functionality - collaborating on code review, receiving notifications on repository activity, managing access control across multiple codebases
* Code discovery - the ability to find projects which use a particular library, search for (and subscribe to) issue reports/fixes, follow other developers' activity
These could more-or-less be achieved by configuring individual repos and setting up your own email alerts and notifications; GitHub & GitLab just make it very convenient and bring it all together in a single place.
I wanted to point out the different "levels" between your own local git repo and GitLab/GitHub. If you're by yourself, a local git repo is great. "One step up," would be a remote git repo you push/pull to (people often use this for encrypted password repos or dotfiles). After that are things like Gitea or Gogs, which add a lightweight web interface. As you move to GitLab/GitHub you start to see features like; accounts, permissions, code search, issues, wiki, pull request, CI integration, etc.
You can use something like GitHub/GitLab for most all of these tasks, but it's a bit overkill on things like maintenance and hardware requirements if your needs aren't great.
In my opinion, I still use straight Git even though we have a GitLab server. We only do pull requests through GitLab when we have a new hire or a contractor. I don't believe that using GitLab to manage the remote repositories has impacted anyone's ability to use Git to get their work done.
In terms of what I would miss if we had to move away from GitLab, it's having remote repository management and continuous integration in one spot. In the past when a new project started, an administrator had to setup the repository and link in SSH keys, that same person had to setup Jenkins for the CI workflow. With GitLab, developers can set these things up on their own.
> If you guys that use GitLab or GitHub or alike would have to switch to pure git - what is the one thing you would miss most?
Github & Gitlab do tons of things which pure Git does not:
- issue-tracking
- wikis / documentation
- release and package-management
- CI
- a free of cost (and effort) "public facing website" for your project by default
- notifications to collaborators
I'm sure there's more I've missed which I would remember in a heart-beat if I was forced to go plain git and were suddenly without, but those are the most obvious ones I can come up with without even thinking.
Gitlab isn't just a code repository, it's an entire DevOps platform. I don't use GitLab, but my equivalent (Azure DevOps) gives me things like automated builds on checkin, runs unit tests against those builds, and one-click deployments to my test and production environments.
On my local machine, there's nothing stopping me from using any Git client I want, including the Git CLI..
We use it. It's great. Extremely secure too, since you can sync over ssh without having to expose a web server at all, since your wiki, tech notes, and tickets get transferred over ssh with the repo then are accessed locally using `fossil ui`. Self hosting, and it is extremely simple to setup. Backups are super simple as well.
Mostly I would miss to organise 50+ developers on one platform. GitLab offers a very good authorization mechanics. Furthermore the CI pipeline is extremely helpful. There is no need to use anything else.
Phabricator is pretty good. I haven’t built serious software using Gitlab, but I have using both Github and Phabricator in various mixtures, and I think there’s a credible case that the world needs more Phabricator. YMMV.
Having contributed to KDE over the years and using the Phabricator in that time the main pain point with it for something like KDE is twofold - 1. it doesn't support the merge request workflow which a lot of would-be contributors would rather have than generating a massive patchset for a feature from a local tree, and 2. the lack of project isolation (having top level issues / commits / etc and second level repo selection vs top level repo that has issues / commits / etc).
I always felt like the second point is what really turns potential contributors off from Phabricator because there is no one "page" in it for a specific project, and unlike a lot of would-be good Phabricator use case KDE hosts all kinds of software with no relation to one another. Having them all occurring in a global issue namespace which is basically just tagged per-project and having to go through several directories to find the same project in different Phabricator applications is just a burden at that point.
I think they also have a Bugzilla, and hopefully they'll move away from that too. (Not because bugzilla is bad, it's just oldschool and makes no sense to keep issue tracking separate.)
We won't, as far as I'm concerned, being the maintainer of Krita, the KDE project that gets most bug reports per year.
Gitlab's issues feature just isn't powerful enough to be more than a developer's task list. Since it's completely label based, it's hell to use when you've got bug reports coming in from non-contributors. Even classifying issues by OS needs to be done through labels...
Did you know you can enable Bugzilla integration on your project?
Take a look at 'Project Settings' > 'Integrations'. AFAIK It will display the "Issues" link but will redirect you to bugzilla, and some other UI integrations.
We already have an integration feature with Bugzilla using git hooks and some keyword in the commit message.
This feature looks interesting, but this feature is sadly only available in enterprise edition.
This is my problem currently with the move from Phabricator to Gitlab, we are losing tons of features: review approval, meta project (documentation, visual design group, promo, website, ...), mockups, meta tasks and more. And those features exist but only in the enterprise edition, that is not open source.
> I think they also have a Bugzilla, and hopefully they'll move away from that too. (Not because bugzilla is bad, it's just oldschool and makes no sense to keep issue tracking separate.)
It does, IMO. Bug tracker categories rarely correspond cleanly to code repositories. And if you have large repositories then GH/GL issue tracking just gets unwieldy.
Phabricator also recommends a whole different workflow than Github/Gitlab with their PR ones. But tbh the task management part of Phabricator is much-much cleaner just because of their Tag system.
But yes, I agree with you, if you use Phab as a code-review or source code hosting platform, it's pretty confusing.
It's possibly also their motive to bring new contributors, since it was recently announced that KDE will be deprecated in the next major version of RHEL.
* Development and maintenance of Phabricator has slowed down a lot.
* People were claiming phabricator was old-fashioned and confusing and hoping a merge-request based workflow would be more inviting
I'm the maintainer of one of the test projects that moved to our gitlab instance, and it's mostly fine, we're missing things in the merge request workflow, but have papered around that with labels (https://invent.kde.org/kde/krita/merge_requests), but we're still using phabricator for task management because it's so powerful for that that we cannot move that part of our workflow to gitlab yet.
Congratulations to GitLab and KDE, I think it will work out well for both. GNOME and Freedesktop are both already on their own instances and it’s been pretty good.
We actually have a panel with representatives from Freedesktop, GNOME, and KDE at GitLab Commit in London (https://about.gitlab.com/events/commit/#schedule)in a few weeks discussing their experience with GitLab.
On a project I contribute to, we ask people to register on our main website, which has a pretty good anti-spam. We do that in part to get to know our contributors more and better engage (after all, we develop a FOSS CRM). Gitlab uses that authentication source as an LDAP server.
So far in the past 2 years, we have had only 1 spam merge-request.
It's good to see Gitlab staying strong, I worry sometimes that if Github has no competition it might turn into a new Sourceforge (which to be fair has cleaned-up its act in the last several years, but only after years of earning enormous amounts of bad will)
Granted with Microsoft ownership there's less chance of Github becoming cash desperate, but it seems possible if somewhere down the line Microsoft loses active interest and goes on life-support, and Microsoft decides that the property is no longer worth protecting from the arbitrary whims and corporate commercial strategies internally.
> Obviously, they weren't interested on that venue anymore.
Because Github and Gitlab was eating up the userbase left and right. The utter lack of any progress/development on Google Code itself was the nail in the coffin driving people away.
> That would be a major reason to abandon the Gitlab ship.
Why?
Gitlab is actually open source. Although we actually pay money to Gitlab for support since it's so cheap. We run our own instances and would be fine even if a FAANG bought it and killed it.
The ability to self-host is actually one of the differences between Gitlab and Github.
Well we do as well but it's tied to a license key that enables specific extra freatures, so if they kill and can't renew it, we would be screwed unless they released a special change or key to disable it (barring someone else figuring out how to remove the key validation, likely against ToS)
There’s a big difference to Google execs between technological and commercial success. It must be very, very interesting to be a fly on the wall of their high level product management meetings.
It absolutely wasn't. It was completely insignificant in all respects to a company of that size. It also has had better alternatives within months of its demise to the point that it's rather surprising people are still missing it.
Basically so the founders and investors can cash out. Investors put money in to get a bigger return, and founders may have shares worth a lot on paper, but that's not money until someone else buys them.
Oracle could be a good candidate too. They have a cloud service and from what I can see their development environment is a mix of basic in-house tools, old-school stuff like Hudson and various open-source projects.
[1]: https://invent.kde.org/public/