The KDE community is moving to GitLab
about.gitlab.com
about.gitlab.com
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.
I would amend that to "source-code collaboration applications". The hosting is not the important part.
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.
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.
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.
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.
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).
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.
Someone mentioned online that Gitlab has a richer markdown format. I haven’t really investigated but I found this a moment ago:
free GitLab account has no edit history. I think it's a important feature for private development
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!
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.
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.
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).
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.
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.
GitHub and GitLab have similar features. GitHub calls them pull requests. GitLab calls them merge requests.
"Press Enter to exit, Exit to cancel, or Cancel to continue."
They are available in base git. The command is called request-pull[1].
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.
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 should really check GitLab out again if the last time you used it / upgraded it was one year or so ago.
* 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.
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.
Not a universal truth.
There's a bit more to it ... and sure all can be done manually.
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.
Oh wait, git over ssh doesn't show a web view.
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.
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.
Think of "Linux" and "Ubuntu". The kernel is necessary, but so is all the user-space on top of it. That's git and GitLab respectively.
What advantage does that have over the standard hooks[1] that git itself comes with?
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.
Not really. It can be done via email using standard git commands like git format-patch, git send-email, and git am.
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.
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.
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.
Gnome: https://gitlab.gnome.org/GNOME
Freedesktop : https://gitlab.freedesktop.org/explore/groups
Arch Linux : https://gitlab.archlinux.org/archlinux
KDE devs correct me, if I am wrong please.
https://invent.kde.org/network/kaidan/-/pipelines/25364
I've tried to find same in the Blender's phabricator and it doesn't look that they have CI support at all.
It can trigger automatically for new commits or new revisions.
Gitlab is much better at the CI part, though, but significantly worse for code review.
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.
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.
For example, GHC moved from Phabricator to GitLab in December 2018, citing ease of contribution as a major benefit:
https://twitter.com/bgamari/status/1069047550727069696
As of April 2020 (about a year after the transition), the GHC year-over-year contributor numbers didn't appear to change:
https://twitter.com/evanpriestley/status/1245817419441926144
(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?
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.
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.
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.
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.
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.
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.
I would pick gitlab over phabricator any day.
(I have been a former KDE contributor)
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.
I have never cared about all the "social features" that work tools seem to always end up introducing...
When I am working, I am not trying to be social but to be professional.
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.
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.
Of course gitlab projects do have RSS feeds, so you could use that I guess.
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.
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.
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.
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.
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.
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.
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.
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.
Would be awesome if you could pick your platform without losing all the devs who only use one platform or the other to discuss issues.
• https://github.com/PyCQA/flake8
• https://gitlab.com/pycqa/flake8
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.
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. :)
Improving frontend performance is a key focus area for us, and while we started this specific initiative recently, we have started prefetching data while our Vue app is loading (https://gitlab.com/gitlab-org/gitlab/-/issues/220511) and will be splitting out page specific assets out of the main bundle (https://gitlab.com/groups/gitlab-org/-/epics/3694).
We have quite a few other initiatives in flight, and will continue to provide updates on progress which you can see here: https://gitlab.com/groups/gitlab-org/-/epics/3273#note_37091...
There was no Subversion when KDE started. Like most projects of its era, KDE started with CVS, and moved to Subversion in 2005.
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.
Gitea don't even have CI/CD.