[HN Gopher] The KDE community is moving to GitLab
___________________________________________________________________
The KDE community is moving to GitLab
Author : caution
Score : 200 points
Date : 2020-06-29 16:57 UTC (6 hours ago)
(HTM) web link (about.gitlab.com)
(TXT) w3m dump (about.gitlab.com)
| cptskippy wrote:
| Did I read that correctly, they were on Subversion before this?
| quantummkv wrote:
| 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
| wheels wrote:
| > _There was no git in the 90 's when KDE started_
|
| There was no _Subversion_ when KDE started. Like most
| projects of its era, KDE started with CVS, and moved to
| Subversion in 2005.
| sho_hn wrote:
| In fact, I recall we had to contribute code to SVN to make
| it scale to our existing monorepo size :-)
| lbeltrame wrote:
| 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.
| sho_hn wrote:
| 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.
| lima wrote:
| Are you still happy with your choice to migrate away from a
| monorepo?
| ahartmetz wrote:
| 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.
| [deleted]
| nikisweeting wrote:
| Has anyone built a bridge that mirrors issues between Github &
| Gitlab? (the codebase can obv. just be synced via git itself)
|
| 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.
| abalaji wrote:
| GitHub and GitLab have visual indications for the mirroring you
| mentioned, example:
|
| * 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.
| x3haloed wrote:
| Great sales pitch. The part that's missing is the most important
| part: why they chase GitLab instead of a competitor.
| tapoxi wrote:
| 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.
| q3k wrote:
| You might be interested in ForgeFed [1].
|
| [1] - https://forgefed.peers.community/
| jfkebwjsbx wrote:
| I genuinely ask: why is "a sense of community" important in a
| productivity tool?
|
| I have never cared about all the "social features" that work
| tools seem to always end up introducing...
| beamatronic wrote:
| Right? If I wanted to deal with people I wouldn't have become
| a computer programmer.
| jfkebwjsbx wrote:
| It is not about being social or not (I am a quite social
| individual), but about the context that I am wondering.
|
| When I am working, I am not trying to be social but to be
| professional.
| zoomablemind wrote:
| 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.
| tapoxi wrote:
| 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.
| jfkebwjsbx wrote:
| 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.
| qchris wrote:
| 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.
| LockAndLol wrote:
| 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.
|
| 0: https://forgefed.peers.community/
| thaumaturgy wrote:
| 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.
| slezyr wrote:
| I can't blame them, GitLab's CI integration is great. Take a
| look at it:
|
| 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.
| thaumaturgy wrote:
| 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.
| lima wrote:
| Harbormaster works fine, though it requires a million
| clicks to set up.
|
| 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.
| slezyr wrote:
| 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.
| thaumaturgy wrote:
| 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.
| techntoke wrote:
| 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.
| Jonnax wrote:
| It's cool that KDE are using the Community Edition if Gitlab
| jsiepkes wrote:
| 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?
| sho_hn wrote:
| 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.
| ragerino wrote:
| That's awesome. Thank you!
| rhabarba wrote:
| 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.
| nfoz wrote:
| 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?
| melling wrote:
| I'd like to know also. Gitlab appears to have a free account
| too; I do pay for Github. Do people use both?
|
| Someone mentioned online that Gitlab has a richer markdown
| format. I haven't really investigated but I found this a moment
| ago:
|
| https://docs.gitlab.com/ee/user/markdown.html
| lotyrin wrote:
| 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).
| Scarblac wrote:
| 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.
| Stratoscope wrote:
| A note on terminology:
|
| GitHub and GitLab have similar features. GitHub calls them
| pull requests. GitLab calls them merge requests.
| bra-ket wrote:
| no master->main renaming bullshit
| mekoka wrote:
| 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).
| beisner wrote:
| 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.
| thaumaturgy wrote:
| 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.
| deadbunny wrote:
| 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.
| fimbulvetr wrote:
| 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.
| ragerino wrote:
| 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.
| g105b wrote:
| 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)?
| burkaman wrote:
| Github Enterprise is $21 per user per month, and GitLab
| Community Edition is free.
| techntoke wrote:
| It is free and open source, unlike GitHub
| Denvercoder9 wrote:
| CI, issue tracker, pull requests, etc.
| jfkebwjsbx wrote:
| 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.
| shmerl wrote:
| Gitlab is replacing Phabricator, not Git. It's a higher level
| tool.
| brnt wrote:
| 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.
| rvz wrote:
| 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.
|
| [0] https://news.ycombinator.com/item?id=22867803
| slezyr wrote:
| It's not about GitHub, it's interesting that they move from
| Phabricator(?) to GitLab.
| rH61W3epxeHMjg4 wrote:
| Many open source projects are self-hosting Gitlab:
|
| Gnome: https://gitlab.gnome.org/GNOME
|
| Freedesktop : https://gitlab.freedesktop.org/explore/groups
|
| Arch Linux : https://gitlab.archlinux.org/archlinux
| mixologic wrote:
| Debian: https://salsa.debian.org/public
| mixologic wrote:
| Drupal: https://git.drupalcode.org
| zelphirkalt wrote:
| Free a.k.a. libre, not open. Ot's even in the name this time
| ...
| zelphirkalt wrote:
| 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.
|
| KDE devs correct me, if I am wrong please.
| ssutch3 wrote:
| KDE is "self hosting" https://invent.kde.org/public/
| zmmmmm wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2020-06-29 23:00 UTC)