What advantages do people like from Gitlab as opposed to just using git? I'm not too familiar with gitlab/github, so I'm sure it's a naive question, but I'm wondering what the main value-add that's missing from the basic tools is?
GitHub and GitLab add project management capabilities to your project.
Both come with a IssueTracker (for bugs, feature requests, ...), a Wiki (for documentation), simple user management, and webhooks for automated build platforms.
You can do things like adding an issue-id into a commit statement which displays your commit in the issue ticket for others to reproduce what exactly was changed to fix a bug or implement a new feature. This can be super helpful when someone wants to extend a feature. Or reproduce why something isn't working any more, and fixing it instead of reverting the code and reintroducing a bug that was fixed (We had exactly such a problem of a reoccurring bug because two dev's didn't understand each others commits)
I prefer using GitLab for my company and private projects, since Microsoft has acquired GitHub. For public projects I prefer GitHub because the user community is larger.
GitLab also comes with extensive project management and DevOps support, and can run on your own infrastructure.
You can run Github on your own infrastructure too, so is the only benefit of GitLab that it isn't owned by Microsoft (the largest contributor to The Linux Foundation since 2005)?
I prefer Gitlab for private installs, but the community edition lacks many critical features that are only present in the paid version (export/import of issues, I'm looking at you)
Yes, but there are multiple open source tools that make this easy and they have an API for it as well. I think the need to have a large monolithic platform for issues is absurd. I probably won't be using GitLab or GitHub for my next project. It totally defeats the decentralized nature of Git.
Maybe you're talking about something else but according to the features page [0], both importing and exporting issues as CSV is enabled for all versions of gitlab.
As other users noted, this feature has recently become part of the community edition. They are currently in a rolling effort to move stuff from paid to free.
You should really check GitLab out again if the last time you used it / upgraded it was one year or so ago.
They contribute, but their repos don't take contributions themselves from outsiders, which is not exactly the spirit of Linux. They contribute to Linux because they see it as a threat they can't ignore and so are implementing stage 1 of their EEE strategy
Fair question, you shouldn't be getting downvoted for it imo.
Larger projects need a way to collect bug reports, feature requests, maintain documentation, and set up milestones and release schedules, at a minimum. Ideally you want all of this integrated into your vcs, so that when a developer decides to push a commit related to a specific bug or feature request, that commit gets attached to that bug or feature request.
When these are set up and run well, they are very powerful for mid-to-larger organizations.
I would like to second this and point out that while someone can self host and set all of this stuff up, at some points there are economies of scale for using a provider to do this because the provider's raison d'etre is to create these interfaces that make it easy for everyone to interact with git. The developers on KDE, etc. probably don't want to spend their time working on the UI for their bug/issue/feature/commit request tool when they could be working on KDE things.
Finally, there's the fact that many more users will be familiar with GitLab (or GitHub, BitBucket, and so on) than they would with each and every opensource project's flavor of bug/issue/feature/commit tracker. For instance, I know exactly how to find the "releases" section on github quickly - if KDE wrote their own bug/issue/feature/commit tracker, I'd have to find the "releases" area and remember where it is every time since I don't use that UI as often as I use github.
Actually, gitlab is open source and the majority of the features aren't pay walled off. You can self host ~70% of the gitlab features on your own hardware, without paying a dime. Or you can self host and pay a subscription to enable all the enterprise features. At work, we use this for code which is too sensitive to host outside of our infrastructure. Closed source development needs management too.
> Fair question, you shouldn't be getting downvoted for it imo.
Well, the question is pretty much answered in the actual article. From the looks of it, this seems to be responding to just the title without having actually read the page.
I would say that hosting on a centralised service like GitHub it Gitlab also reduces friction for contributors - bug reports, code, docs - as people will usually already have an account so they can make drive by contributions.
Having to find a bug tracker, create an account, log a bug is a lot of hassle for a random library or small project. I know I've given up raising bugs for some things as I couldn't be bothered with the rigmarole of sign-up, verification, etc... On Gitlab/GitHub there is much less friction because I use both regularly and and can use them for multiple projects, large and small.
It uses maildir files in a hidden directory, which can be tracked like any other files; e.g. when committing a bug fix we can also commit the closing of the associated issue. I've also configured Emacs to make using it even smoother (opening issues/comments in a derivative of message-mode for syntax highlighting, with a C-c C-c binding to save and stage; I've partially finished a derivative of tabulated-list-mode for browsing issues interactively).
off-topic: I'm around HN for >10years and I vaguely remember a UI change where I could not see some voting counters any more. How do you know if a comment has been voted or downvoted?
When I first replied to the parent comment, it was gray text -- HN's UI for "this comment has less than one point". I couldn't tell you the comment's score right now. It doesn't look like hn.algolia.com has comment scores anymore either.
I remember that UI change. At the time HN was really starting to look like it was getting gamed, with comment scores having too much influence on popularity. HN's response to hide scores seems to have helped.
Gitlab has an opinionated (and mostly open source) toolchain and set of practices for proposing, implementing, validating, operating, and monitoring software and changes to that software built on top of Git at one end and Kubernetes at the other, with lots of configurable escape hatches to override its smart defaults when/if you need to.
I haven't really seen anything else quite like it (though it does have a long way to go still).
People try to roll their own from-scratch solutions or plug in an off the shelf tool here or there and their idea-to-production pipelines are generally worse or incomplete in comparison. Most of the architects of these things only care about their corner of the solution space and the rest are either neglected or have their own champions and their own siloed solutions.
Nothing off the shelf quite resembles it either. If you e.g. buy and use the entire Atlassian suite and train and get everyone to agree on the desired flows and practices, so much is left to you to design that no two such systems are likely to be similar, nor (in my experience) is any one such system likely to be very effective or efficient in daily use.
I'd really enjoy seeing Gitlab mature and expand, I would love to work at an org that adjusted itself to fit something like what Gitlab is trying to be, instead of trying to make their hodgepodge of tools adhere to their personal tastes and political dynamics, etc. (a Sisyphean task as those landscapes are under constant arbitrary change).
This is it. Most other answers focus on one or two things gitlab does, but the essence of Gitlab is that they provide a platform for the whole development cycle, including planning, design, deployment, monitoring, analytics, incident management, etc.
They can do this by using the best / most fitting open source software for each task and integrating it, also by focusing mostly on kubernetes while still providing enough flexibility for other options. You just don't get to use the whole feature set if you're not on kubernetes.
Git is a version control system, whereas Gitlab/Github are source-code hosting applications. You use git to interact with Gitlab/Github.
Without going too in-depth, they allow teams to set up accounts on a central website, where team members can contribute to that central git repository. There are also other project-management features baked into the tool (code review, issue tracking, etc).
Of course, this can all be done using a bare git server running on some publicly-available computer, but they offer nice UIs and very friendly onboarding so that makes them attractive for teams.
Pull requests are the thing they offer that is closest to Git itself but not available in the base Git. It's a code reviewing tool to use before merging branches.
Developer A has a branch that he wants to merge with the master branch. He opens a pull request for that merge, and Developer B can look at the diff online and _comment on it_. On individual lines or blocks, or on the PR as a whole. The comments can become discussions, new commits can be added to the pull request and the comments are marked as outdated if that code was updated, when everything is OK developer B can press an "Approve" button and the branch can be merged.
As far as I can tell, all this does is generate some text that you can email to someone. It doesn't offer the ability to iterate on code reviews or track line comments, so you'd have to manage all that either via email or via a separate system.
It really depends on how you define the term pull request/merge request/request pull. The end action is to merge the code in the set of commits into a local branch, which is what all three allow you to do.
The ability to discuss code changes, etc, is separate from that. In my opinion, the terms pull request and merge requests are not entirely accurate. For services like Gitlab and Github, it's essentially asking the maintainer to review your code, so it really ought to be called review or change request.
Aha. I was already thinking: what does Gitlab add next to Phabricator? And the KDE Bugzilla instance. Will that be moved over as well? KDE has many parallel systems like that unfortunately.
Gitlab is replacing Phabricator but not Bugzilla. Gitlab issues are going to be used for developer task tracking but Bugzilla will continue to be used for end-user bug tracking.
Why not Bugzilla though? Gitlab bug tracking looks much better to me. The switch worked pretty well for Mesa which was also using Bugzilla before. Bugzilla feels clunky in comparison.
* KDE has gone through CVS, SVN, Git, Redmine, ReviewBoard, Phabricator and now GitLab for various source control needs over the years, all while still using Bugzilla for bug tracking. There is a lot more intertia to overcome.
* GitLab (and GitHub etc.) are organized around code repos but the hierarchy you use to organize your code isn't necessarily the best hierarchy to organize your bugs. There are a few different "plasma" repositories but end users aren't going to know which one the bug about their panel spazzing out on leap seconds goes in. So you consolidate everything into one Plasma project. But then your code and bugs aren't living together anymore, and using GitLab for the bugs buys you very little over just having good integration with Bugzilla.
* It's a lot easier to move bugs around between projects and they keep the same identifying number.
Why can't it be integrated with Gitlab? And if some old one is hardcoded to use Bugzilla, there can be automatic import to Gitlab as well. I.e. Bugzilla can run for those automatic reports, but not for anything else.
Most of the replies to your post are inaccurate. Yes Gitlab and Github offer a ton of value-adds like issue tracking and project management, but the core reason for using them is to get a fully managed Git server vs hosting one yourself.
If you have ssh access to a box; you have a git remote.
It’s obscenely simple, and contra to your claim the “managed” aspect is not the selling point of this software. The selling point is the project management features and integrations.
In githubs case it’s a managed service.
In gitlabs case, I can be a managed service or it can be a software suite you maintain yourself.
Sure, so now instead of just having a source control remote, you’re now looking after a publicly accessible box in the cloud with all the security headaches that brings. Plus you’ve got to manage credentials essentially manually, make sure people have the right access permissions to repos, look after backups, etc.
I worked at a company that started out with a setup like this for the dev team. It felt like a massive burden was lifted when we moved to Github Enterprise. We weren’t using the project management features at all, just the source code hosting stuff.
This is actually an absolutely awful idea. Every time I used the code browsing and search features I was disappointed by how poorly the search is working. Lots of false positives. Usually fail to find what I'm looking for. When I git clone something and use my text editor's search feature I usually find what I'm looking for on my first try.
It's not perfect, but for a lot of smaller projects it's fine.
Also way easier to send someone a web link to something in a discussion to have them look into it, especially if it's in a different branch then they may have.
> I want to browse it real quick and look over it, before I pull it
What's wrong with fetching it, checking it out in a local branch, and browsing it using your editor? It probably is much easier to browse the code, see it in context and see the diff using your editor compared to the web interface.
The ssh host doesn't do git hosting. You have a hard time to manage ACLs and have to restrict users accordingly. Also you need to run an http server and update the git cache if you want to support anonymous requests to the repo.
There's a bit more to it ... and sure all can be done manually.
Git hosting over SSH does work. I've seen it work well. We already had ACLs set up for other reasons, and we didn't need anonymous requests. It's the simplest thing that can possibly work; don't add extra complication if it's not needed.
Git is still what you use to manage your project's "snapshots" at any given time. But GitHub/GitLab add a plethora of tools to make it easier to manage your project and facilitate collaboration. In addition of offering the service, GitLab gives the possibility to host your own copy of their solution (it's open source).
You _can_ use only git but you get into several problems if you are in a team larger than one.
Sharing code requires the git server and open network ports on your development computer. With non-static IP you can't point to your peer's computer without needing to change the remote settings every time you sync.
Basically, for convenience, you will need a git server accessible to your team to sync up code in a 1-many fashion instead of the many-many raw git. Github/gitlab provide exactly that with added features on top. They differentiate by the added features only.
With the usual caveats applied to embedding and extracting patches from emails.
I don't find email-git much more convenient unless I've been living under a rock and it got much easier using the free email providers for git in the last few years.
> With the usual caveats applied to embedding and extracting patches from emails.
Which are? The settings in git format-patch and git send-email will handle embedding and sending. Also, as long as your email client can save emails to disk, git am can do the rest.
> I don't find email-git much more convenient unless I've been living under a rock and it got much easier using the free email providers for git in the last few years.
I've tested it with my ISP email (Comcast) and Gmail. Other than having to enable "insecure" access for Gmail, there wer e no problems at all. Hotmail/Live on the other hand, would mangle the email message.
First level of value is simply a hosted, reliable git hosting for any size of team. Second, is the pull or merge request workflow which really makes coordinating development a lot easier. Third, is automation - webhooks and such make it really easy to connect different tools to your repo (i.e. analysis, linters, CI/build or even deployment scripts. Fourth, there's all the documentation and project management.
What specifically about line breaks is a headache? Would you prefer that pressing "Enter" automatically inserted a line break?
As for edit history, I'm assuming you are talking about the description edit history. If so, we had an open conversation (https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_206...) about why we placed the feature in Starter and above. If you'd like to continue the convo, please open a new issue with your proposal. If you are talking about a different edit history, please clarify so I can better understand your perspective. Thank you for the feedback!
Yes, I perferred "Enter" for linebreak. Double "Enter" just not the best for us. Sometimes, we drafted the comment or description somehwere before copy into Gitlab. All lose! Some of our customers given up to fix the format and post screenshot PHOTO directly. It's very frustrating.
Regarding the edit history,
both description & comments edit history are important to me. We can only afford our freequent customers and one time projects. You know, many projects holding for months and no earning at all but you can't cut it.
When those projects started, not much. They offered Git storage and an issue list, pretty much.
Then they started to grow, specially GitLab in the beginning, and now try to be a single centralized solution for all software development needs like Atlassian, IBM and others had always been selling.
Great news for KDE and open source. Self-hosting with something like GitLab, Gitea, etc is still an option if you are dealing with an open-source project like GNOME, Xfce, etc. This allows you to control your data, source-code and the server if it goes down with the sys-admins to maintain it and you can still mirror your official repository from GitLab/Gitea to GitHub.
It isn't a good idea to 'centralise everything' [0] on a server or VM instance that you don't own, which is why self-hosting is better for companies and open-source projects than on GitHub.
I think KDE contributors are mostly knowingly contributing to free (libre) software. To call this only open source does a disservice to KDE as a community. It's not the nicest thing to say. I guess you were unaware of this and not intentionally mixing up the terms. I think KDE devs would pro ably disagree with you calling it only open source.
Jumping onto one of the most popular source control platforms is a really good move for KDE, but I'm a bit disappointed to read this. Phabricator is a really excellent piece of software, and seeing large projects like KDE running on it gave me hope that it would have a long life ahead still.
It's 2020 and phabricator still requires users to use an amazingly buggy seperate CLI (arcanist) to create pull requests ('diffs'). Because it is not that widely used, good luck on finding solutions to the many issues you might encounter. The workflow with arcanist also differs in many ways then simply using git.
No way to create pull requests from the UI.
The UI itself is amazingly slow and clunky (wait for all the files in the diff to load before being able to click anything).
On top of that it has fallen way behind on simple third party integrations that GitHub and gitlab enable.
Yep. Phabricator kiiiinda has CI through Harbormaster, but it's not well documented and only sorta kinda works, and if I remember right, requires running arcanist commands locally. It's way far behind what other platforms are doing.
Ah, it reminds me of another issue - AWS-type naming (harbormaster, maniphest, phriction, diffusion, differential) I simply can't what are those without clicking them.
The naming style wasn't great, but you get used to it, like anything else. The architecture itself was beautiful; rather than trying to build a single monolithic application, the developers built a federated suite of applications that all shared a common architecture. This made it possible for the developers to treat each Phabricator component as a separate project and also allowed Phabricator administrators to set up a la carte configurations according to the organization's specific needs.
There are many high-quality CI platforms that integrate into Git that look great. It doesn't have to be built into a large monolithic platform like GitLab. I feel like this is a bad decision too. You'd think they'd at least move to Sourcehut.
I enjoyed using Phabricator but the barrier to entry is too high for a community project like KDE which needs every new developer it can get. Just a few small hurdles are enough to put people off.
I actually just wanted to replace an icon size dropdown (pretty dumb idea if you ask me) with a slider and a preview of the size of the icon. The reason why I gave up is that I couldn't find the original repository. For some reason the KDE team decided to only link at https://invent.kde.org/ and never actually specify the actual repository. Heck, even the github mirror doesn't show the link to the real repository. When I search on invent I just find lots of unrelated forks. This wouldn't be a problem if they were actually linking to the damn projects.
Can you point me at any data which supports this? It seems like it should be true, but GHC didn't appear to see a year-over-year increase to contributors when they switched from Phabricator to GitLab in December 2018.
I added another comment to https://news.ycombinator.com/item?id=23686803 about case studies we hope to do about this. So while we don't have any to point you to today, we hope to have some in the near future.
Another thing that we hear from people considering a move to GitLab is that they really like how fast GitLab moves (one release per month!), and how it works with the community to keep improving the product. I recently joined as the Sr. Open Source Program Manager as part of the Community Relations team, and we're thinking a lot about how to continue to improve the experience for our community.
In my view, refocusing the roadmap on only requests from paying customers was possibly the best change I've made for the health and longevity of the project.
Let me say up front that I'm a die-hard fan of Phabricator but not a paying customer. I have no idea how you've managed to build and maintain that project, it's amazing.
Paying customers hire developers, and developers always, always create pressure within their organizations to use the tools and software that the developers are most familiar with. A few developers in this thread have mentioned some things they've struggled with; I've spent a lot of hours reading Phabricator documentation, sussing out Conduit, trying to learn how to use the whole system well, and there are still lots of gaps in my knowledge. When Phabricator becomes too different from the workflows that developers are accustomed to elsewhere, and it isn't immediately obvious that those differences make it better than the alternatives, then they're going to pressure their organizations to not use Phabricator.
Developers furthermore are always looking for ways to build their resumé. The further away Phabricator falls from being used in big, well-known, popular software projects, the more it becomes a hindrance to resumé-building. A developer can add GitHub or GitLab familiarity to their resumé for extra credit, and GitHub public profiles are a good way to say, "Hey look, I write and ship code on a regular basis". If I'm trying to get hired, and I want to learn about integrating CI, I might have to choose between GitHub Actions or Harbormaster. One of those is far, far more valuable for resumé-building than the other.
I can't argue with your focus on paying customers, but if your developer community isn't big and healthy, your paying customers will eventually not be, either.
Open source projects generally want an exact feature-for-feature copy of GitHub that looks and works exactly like GitHub, except open source.
If Phabricator was this, there would be no reason for paying customers to ever choose it over GitHub, because paying customers generally do not care if a solution is open source or not.
But the bigger impact of this change was not a product impact at all: it was that interacting with paying customers is something I generally enjoy and feel good about, and interacting with open source users is something I generally hated and felt miserable about.
For whatever reason, Phabricator attracted a large number of users who wanted to argue with me about every technical decision, insist that whatever feature they wanted should be the highest upstream priority, suggest I should pay them for their "valuable suggestions" because they are an important CEO, take offense when I asked them to please please please read the documentation and provide reproduction instructions, bump every open task asking for status updates, etc. This stuff had a huge net cost to the project and only got worse over time as the project grew.
Writing off open source installs allowed me to stop dealing with all of this.
The workflows of Phabricator, having Tasks as Issues and attaching patches to them is way archaic to how people who are used to Github do things - they fork, make changes, and submit merge requests.
If you want to solicit outside contributors you pretty much have to support this model or you will lose a sizable fraction of potential devs.
(I'm not sure this is a fair comparison, and am not aware of other possible changes to GHC during those years, and bear in mind that I'm a highly biased party.)
Can you point at a project which made a switch like this and saw an actual significant change in contributions or contributors afterward?
I'm not the OP. However, speaking from my own experience using Phabricator for the first time: I wanted to send a small pull request that fixed wrong mouse cursors being used on Chromium-based programs. The fix was literally symlinking a couple of files. This issue was on Breeze_Cursors from KDE, by the way.
It took me half an hour to read the KDE documentation on how to contribute, then set-up my workflow, learn how to use arcanist; to only then, submit the pull request. Thankfully my pull request was accepted right away, because had the developers requested code changes I would probably have to spend some more time having to deal with arcanist again.
I'm not gonna lie, having to use a totally different workflow from the ones I was used to (Github, Gitlab and the like), just to submit a small change, was a little frustrating. Ah, one more annoyance (although not related to code): The two-factor authentication system used in KDE's Phabricator is _so stupid_ that I wish I hadn't seen it.
I can totally relate to this. In fact, just a few months ago I complained here about the steep entry bar for KDE projects.
Now, ever since moving to Gitlab not only was I able to successfully contribute, but I effectively became a co-maintainer of one of the projects. We also had some pull requests from some "hit and run" coders previously unknown to the project.
It's 2020, nobody wants to waste hours to learn how to contribute to an open source codebase. I can't think of a bigger deterrent than a complex, unorthodox approach that KDE had previously used.
> It took me half an hour to read the KDE documentation on how to contribute, then set-up my workflow, learn how to use arcanist; to only then, submit the pull request.
Couldn't the same argument be made for having to learn a language in order to even contribute code to a project? Learning how to collaborate using different systems isn't really different than having to learn different languages, conventions, or code styles to contribute to different projects.
Just to add to this discussion, I work at GitLab and we have it on our roadmap to write some case studies about open source projects using GitLab. It's great to hear people's personal stories with regard to contribution being easier, and we hope that the case studies will serve as another reference for people considering a move to GitLab.
As someone who casually contributes to various projects, I do find Phabricator a block.
GitLab/GitHub are ubiquitous (let's face it, learning one of them is learning both of them), so contributing to any project that uses either (or a clone) is simple.
Something dramatically different with custom tooling and flows is a barrier of entry, that might discourage one from jumping in.
Since there's other large open-source projects on GitLab too (namely GNOME) I think it would be pretty neat if there was some sort of ActivityPub-esque federation between GitLab instances, to foster a sense of community in an application that's more distributed than GitHub is. You miss out on a lot with so many teams living in their own bubble.
Software is a collaborative effort, and the easier you make it to collaborate and share information with others, the better. Imagine @ing a GNOME dev in a different instance to comment on a bug report in KDE, or seeing an newsfeed update that your favorite framework is making a breaking change in the next release, or opening a PR/MR in another project without having to create _yet another_ account.
You don't need to use any of those, but I think that the large community is partly what makes GitHub such a valuable tool.
> Imagine @ing a GNOME dev in a different instance to comment on a bug report in KDE
How do you see this being different from providing that dev with a hyperlink to the bug report? In either case, the developer is made aware of the issue, no?
> or seeing an newsfeed update that your favorite framework is making a breaking change in the next release
I don't actually know if changelists have RSS feeds, but supposing they did, couldn't you subscribe your reader to those feeds to achieve this result?
> or opening a PR/MR in another project without having to create _yet another_ account.
Yeah, you got me here. Though I'm leaning towards "build a physical key that automates account creation everywhere" so you still have a zillion accounts under the hood, but that's mostly transparent to the user. Sort of like Facebook/Google SSO, but instead of storing data in one data-hungry corp's DB, you're generating essentially random data in one place (your physical key) and distributing it across zillions of little DBs, thus reducing the incentive for hackers to try to obtain any of them.
This is a good answer, but the feature you mention sounds to me like it is useful because it is a productivity feature (avoiding time creating accounts and switching tabs in a browser), not really used for socialization.
Like when telephone lines were introduced, they were a massive boost to productivity. Even if they could be used as a social feature within companies, it was not why they were useful there.
Not really. What you're talking about is OpenId/some sort of OAuth. The parent comment is talking about mixing the activity from a bunch of projects into one.
Of course gitlab projects do have RSS feeds, so you could use that I guess.
I have use GitHub to host some of my professional work that is publicly available, and I do use it primarily as a productivity tool with the benefit that I can link other people to it if they need to.
However, I find the "sense of community" features on GitHub to be really important, because I also do a lot of unrelated open-source work as a hobby. In those areas, I'm able to follow people who are coding things similar to mine. I'm able to see when they create a new project, and seeing their stars often leads me to new tools that I find useful. I'm hopeful that the people that follow me or my repositories feel similarly. A sense of community helps to make me enjoy the work I'm doing a little more.
It's kind of like running into someone who's looking through the same section of the hardware store as you. I'm not going to the store to talk with them, but if I end up having a nice interaction with someone who's working on something similar to me or having the same problem I am, it usually brightens my day a little bit.
If you're an open-source project, the community aspect allows a better engagement of ... community, that is devs, users. For devs that means reviews and interactions, for users - issue reporting, maybe some support.
Integration of community features improves visibility and situational awarness. Compare this to emails or IRC, or forums.
Of course, effectiveness of this is as good as the ability to manage the vast information that get generated in open projects like this. What's the point of having everyting in one place if it's hard for users to find the information they need, or if no one is able to properly care for the tons of issues raised from the community... Anyways, GitLab is a tool that helps one organize and tie together these streams of project information.
>Integration of community features improves visibility and situational awarness. Compare this to emails or IRC, or forums.
What do you see being some benefits over the older tech? Because when I think "community features" I'm picturing something like Tweetdeck for devs (which, in fairness, may be completely different from what you're picturing). Basically, this repo I'm watching had these updates. That sounds like the same thing I get in email from an issue tracker, complete with comments from others watching.
> What do you see being some benefits over the older tech?
Think of a remote-first collaboration arrangement. In such scenario the concentrated communications become vital for collaboration efficiency.
'Old' approaches could work too, emails can be typed and sent with a right set of CC, also IRC can be set up for chats, teams can roll their own messaging tool of choice.
It's all about policies and consistency in adhering to them. When these features are devised together as part of a tool, it offers to a client those policies out of box. Thus, feature planning or collaborating on a merge request becomes more transparent, perhaps more real-time, when the tool supports the 'social' features.
Just a feature as simple as "@user" mention notifications may promote the level of collaboration.
Hopefully with the coordinated move to gitlab and the now greater existence of Gitlab instances, there will be a push towards ForgeFed[0] which will allow cross-instance merge requests, forking, issue creation and more.
I imagine it would make collaboration between different instances / groups easier e.g a KDE developer won't have to create an account on Debian's gitlab in order to fork a project or create an MR, but simply stay on the KDE instance, do all the work there and then submit a cross-instance MR.
I think this is great but the "Why KDE moved to GitLab" section is downright weird - doesn't seem to provide any clear reason why and mostly talks about how hard it is. Why put that section in if then to not properly address it? It is almost counterproductive because it makes me really wonder now why when they can't actually state a clear advantage.
KDE moved because Phabricator is practically abandoned and KDE can't take it over.
Furthermore, all KDE development is based on git and Phabricator abstracts the versioning systems, making the naming of things weird. They require weird cli integration (arcanist) not to rely on git semantics.
Most contributors expect gitlab/github kind of workflows on the other hand. It's really not great to make newcomers learn how to use arc (which is really not that good and barely used elsewhere) when they can learn proper git commands that will be useful for them in many aspects of their professional life, or just reuse the knowledge if they're already familiar.
I understand whoever wrote the article didn't want to be complaining about Phabricator as much as talking about how good gitlab is.
Did facebook stop using it internally? I'm personally in the phabricator camp, but if it lost the backing of facebook I'd be seeing the writing on the wall.
I was kind of scratching my head here too. It didn't say what platform it was on previously, what limits/ benefits they were looking for that made GitLab appealing. Just "It was the next logical choice"... why did they name the article "Why the KDE community is #MovingToGitlab" when they barely breached the topic?
There's certain projects that you could leave and come back to after a few years and they're largely the same. But it's amazing how much more reliable, efficient, and user friendly KDE Plasma is even in a few short years.
So how do they deal with (what seems to me) basic functionality that the Gitlab community edition is missing? Like for example linking issues as related?
We told our friends at GitLab from the start that we would be running the Community Edition, as our policies and principles require.
During the eval phase mentioned in the announcements we worked out a list of blockers we saw in adopting the GitLab CE, some of which had existing solutions in the GitLab Enterprise Edition. We submitted this feedback to GitLab, both via a master account ticket we kept with them as well as by being active in individual tickets. We also aligned our requirements with other open source communities around us (e.g. our friends at Gnome and VideoLAN) to take opportunities to communicate them with one voice.
As a result some functionality of GitLab EE has been migrated to GitLab CE (or GitLab Core, which both build on, to be correct). A very important one for us just recently in 13.1 - Merge Request Reviews.
We're really happy that GitLab takes feedback from the open source software community seriously and engages in productive dialog about it wrt/ the CE (a good relationship with upstream has always been #1 for KDE's tooling choices). Conversely, KDE has a long and proud history of lifting up the communities relying on the tools it adopts (we've contributed in significant ways to SVN, valgrind, CMake, gitolite, Redmine and many other tools we've been using over the years) and we're happy other users will benefit from the more powerful CE. --Eike, KDE e.V.
I'm not aware of any tools that sync issues between the platforms. But, I'm sure someone could build something to set that up using GitHub Actions / GitLab CI.
I think it's a mistake for them to leave phabricator. This product is quite easy to get ci/cd going on. There are apis to submit back to tickets. it's highly customizable. Also the damn system never breaks; even when you think it broke. Git pull and run the migration tool. boom. Its a PHP system after all. Probably one of the most well written and methodical codebases out there. Also the community fixes bugs regularly, especially if they're simple and easy to replicate.
All of which you get with Gitlab plus a first class CI/CD system out of the box and a more popular (read familiar) interface which reduces the friction for new developers to get started with KDE.
My small problem with gitlab is that the website is slow and heavy JS, especially having to use it on mobile (expectable that you can respond in issue trackers from mobile).
GitHub is comparatively faster and less cluttered UI.
I know this is not a significant problem. But I mentioned it since Gitlab people are sometimes commenting here. :)
We started seriously looking into git in 2007/2008, then launched git.kde.org in 2010. We had set ourselves the goal to lose zero history, and doing a perfect import while transitioning from a monorepo (with lots of interesting code movement within the hierarchy) to hundreds of individual repositories was quite challenging back then! We had to invent some of the tooling (svn2git) along the way.
We're pretty confident it had a positive impact overall. Our repo boundaries match our source archive release deliverables (source tarballs) since the switch. The consistent chunking, also in the build system (i.e. components finding each other during build - before mostly packagers were exposed to this, post-switch every dev is implicitly), helped us along in splitting/modularizing/tiering especially our libraries. It's made us more conscious of dependencies and made it easier to swap things out to rejuvenate.
The community has seen some challenges with drifting apart along the way (projects isolating vs. working on common themes/initiatives), but I think this was more a side effect of overall growth than just the repo reorg. We've also since combatted it with the very successful community-wide KDE Goals election process.
We've stuck to the same ACL approach throughout, notably - you gain KDE dev rights through a peer-support process based in merit, and once you have them you can push to any repo. We mandate code review through strongly enforced social etiquette, not by ACLs.
It was Subversion until 2010 or so. After that, Git with... I think Reviewboard (and various other tools), then Phabricator, soon (and some parts already) GitLab.
Only the translation communities, according to the article. But I wouldn't be surprised if more of the repositories were on subversion. There was no git in the 90's when KDE started
There is still some websites on SVN but I started moving them to git. The only one missing are the one from unmaintained project that I should import in git and then archive.
Only the translation teams use SVN (and perhaps some very old websites, but I think most if not all of them have been moved to git). All the code lives on git, instead.
How fitting: One of the most over-engineered desktop environments moves from one obscure hosting facility for the most unnecessarily complicated version control system to another.
