Hacker News new | past | comments | ask | show | jobs | submit login
Gnome has moved to GitLab (about.gitlab.com)
640 points by fiveFeet on May 31, 2018 | hide | past | favorite | 201 comments

… and closed about a bazillion bugs I filed over the years in the process without (apparently) migrating them, too.

… though I am pretty sure they left the bugs in the source intact.

Everyone on the CC list for each bugzilla bug was notified 6 months ago that any bug without action in over a year would be frozen instead of migrated.

(Do keep in mind that GNOME, unlike corporate projects, is largely volunteer based and time, resources, and contributors are limited)

As the email said, you just needed to ACK a comment on the bug to keep it alive and ensure its migration.

Given the nearly 900,000 bugs filed in the life-span of bugzilla, I think that was an acceptable trade-off given the very small workforce.

Hopefully, the gitlab tooling will allow us to track things going forward much better.

Personally, I think a lot of bugs in Bugzilla were just left open instead of closed due to a difference of opinion/vision but different maintainers have different triage styles.

I wish it was that simple, but I never received a single notice of the migration or my need to do anything at all as a bug reporter. (Just ran a liberal grep on my inbox right now.)

The only notice I received was after-the-fact. Sorry.

Learning of GNOME'S cavalier attitude toward user reports and eventual product direction was exactly why I moved off the platform in the intervening years. I had high hopes when I was young and naive.

I realize GNOME is volunteer-based with a pillar of corporate backing from Red Hat and similar, but it strikes me as botched that if enough will existed to migrate to GitLab, an endeavor that requires serious engineering hours of research and planning and execution, that nobody could have said: let's query and build a list of unique email addresses from bug reporters and personally email them once with a quick letter, letting them know what they need to do. Compared to the actual migration, that is drops in a bathtub. Simple due diligence for user-facing goodwill.

I want to be sympathetic — really.

JWZ's CADT supposition has a lot of explanatory power here combined with the opportunity to "scrub a lot of bugs quickly".

Link for Jwz's cadt post https://www.jwz.org/doc/cadt.html

(edit: I didn't see it was already posted below)

Quick reminder: JWZ despises HN, so you'll need to copy-paste that link in order to remove the referrer header.

Is there a blog post or something that kind of gives an overview on why JWZ hates HN? I'm really curious to learn about the animosity.

I'm not saying the bridge has been repaired, but clicking that link doesn't seem to redirect to... THAT... image any more.

FYI - For me it auto-redirects to: https://imgur.com/32R3qLv

I tested the link, but I didn't get the redirect. I would have added the warning if it happened to me.

This could be fixed with rel="noreferrer noopener" added to the links, would that be a beneficial addition to HN?

Bug reporters who can't even be arsed to follow up or check in on their reports aren't worth nearly as much as you seem to think they are.

True, but on the other hand bugs can go unfixed for years, with developers ignoring them or prioritizing them super ultra low. I know I've opened enough bug reports over the years that I can't go back and check on all of them, but I'm still hoping they'll get fixed some day.

If it's closed for "inactivity" while I'm actively waiting for a response from the developer, that's going to annoy me.

What exactly do you mean by "actively waiting"? Is your act of waiting actively in any way perceivable to anyone but yourself?

As opposed to having forgotten about it. As in, if the developer responded, Github would send me an email and I would jump back into the conversation. As in I can't do anything more until the developer responds, but once they do I'm ready to help.

There's a quick and easy way to tell if someone is actively waiting: respond to them.

The reports may still be relevant. If the problem is easily reproducible or even just well described, a bug report should be useful independent of the activity or further engagement of the reporter.

Why would you "check in" in the presence of e-mail notifications of new developments? Most projects also don't like it if you post "bug still exists" every few months.

Reading email notifications would count as checking in, I don't know why you assumed otherwise.

The parent explicitly mentioned that they did not get the e-mail notification they were supposed to get, suggesting they were subscribed to the issues. So if waiting for e-mail counts your criticism doesn't seem to apply.

> Everyone on the CC list for each bugzilla bug was notified 6 months ago that any bug without action in over a year would be frozen instead of migrated.

What's the relationship between the existence of a bug in the codebase and the propensity of the bug reporter to respond to an email?

> Personally, I think a lot of bugs in Bugzilla were just left open instead of closed due to a difference of opinion/vision but different maintainers have different triage styles.

How does Gitlab prevent those same maintainers from creating that same problem again?

> What's the relationship between the existence of a bug in the codebase and the propensity of the bug reporter to respond to an email?

It's not clear to me the question here, can you be more specific? Many bugs filed are not necessarily bugs in the codebase.

I do wish we treated bugs and user support separately. I rather prefer the terseness of an engineering journal for what it is, but that tends to anger those expecting user support.

> How does Gitlab prevent those same maintainers from creating that same problem again?

In Bugzilla, the only real option we had was "Closed: WONTFIX/NOTABUG" which almost always resulted in hurt feelings on the part of the bug reporter.

I think the gitlab tooling allows us to be more diplomatic in closing bugs that are out-of-scope or not aligned with the goals of the project at large.

> In Bugzilla, the only real option we had was "Closed: WONTFIX/NOTABUG" which almost always resulted in hurt feelings on the part of the bug reporter.

> I think the gitlab tooling allows us to be more diplomatic in closing bugs that are out-of-scope or not aligned with the goals of the project at large.

Can you give more details about this? Closing is closing and Bugzilla allows you to name your statuses whatever you want, so I don't understand how GitLab would change anything.

My experience is that GitLab (and GitHub) is worse in tracking bugs compared to Bugzilla (I've triaged about 10k reports).

I also think having the cut-off at 1 year is a bit drastic. I would have gone for 5 years.

My mistake, it was 5 years for projects that did trim. Most projects brought all bugs over afaik.

> It's not clear to me the question here, can you be more specific? Many bugs filed are not necessarily bugs in the codebase.

Right. So your goal is to separate reports about bona fide bugs in the codebase from reports that either a) are no longer bugs in the codebase or b) are issues outside the scope of the codebase. That's a laudable goal.

Filtering out years of bugs based on the lack of timely response from a submitter (or others) doesn't seem like a sound way to achieve that goal. There's no clear relationship between a lack of response and the relevant bug's existence/non-existence.

I know that I for one steer people away from projects where serious bugs go unfixed for a long time. I have very little incentive to follow up on them once I’ve switched tools.

The correlation between bugs that matter a great deal to me and bugs I don’t respond to is much greater than zero.

If you delete all the bugs that caused people to abandon your platform then you are cutting off your own nose.

Can’t reproduce is a better metric but only if it’s other users rather than the maintainers. I find that a lot of people who write buggy code also are bad at reproducing issues (which I think is why they have bugs in the first place. Lack of imagination or rigor or both).

A "WONTFIX/NOTABUG" closure at least gives confidence that a bug was investigated. Do we know how many bugs were still pending investigation here, prior to being closed due to this migration?

> I do wish we treated bugs and user support separately.

Why not have a buck tracking system where only contributors have write access and a second system where users can submit their reports?

I oppose this sort of thing and rather encourage forming a strong QA team to separate the fluff from the real deal.

The problem is that apparently they don't have this team.

In the face of that reality, a separated internal and external bug trabkin system might be a viable solution.

This would cement an alternate reality, where the growing of the QA team would become more difficult. Trust me, I am talking from experience of recruiting and onboarding hundreds of volunteers into FOSS teams (with varying levels of success and involvement). Recruiting volunteers to FOSS is insanely difficult and any addition of complexity will just result in more headaches.

Intentional or not... you pretty much agree with jwz: https://anonym.to/?https://www.jwz.org/doc/cadt.html (https://www.jwz.org/doc/cadt.html - jwz has some nasty opinion about hn visitors - so the first link omits the referer)

> jwz has some nasty opinion about hn visitors - so the first link omits the referer

I prefer to just not go. If he doesn't want the likes of me there then I'm happy not to waste effort trying to pay attention to whatever it is he is saying.

It did not omit the referrer for me.

This might help in the future if you use Firefox: https://feeding.cloud.geek.nz/posts/tweaking-referrer-for-pr...

A quite safe value from there is

  network.http.referer.XOriginPolicy = 1
which will not send a referrer to third party domains outside of the base domain.

replaced the link, but anonym.to is also sketchy...

> (Do keep in mind that GNOME, unlike corporate projects, is largely volunteer based and time, resources, and contributors are limited)

All the more reason not to undo the work of its contributors.

There were bugs that the Gnome devs refused to fix even with patches. And not stupid patches, but reasonable ones.

It looks like at least some projects got bugs imported. Maybe this is still ongoing?


Don't worry, those'll be cleared up in the next rewrite.

...In which they delete the entire feature you reported as broken, as seems to be the current GNOME way of doing things.

And next bazillion bug will appear!

The bugs I've reported are migrated over. And I'm not on the hook for getting update emails either, so it's a win-win.

Are your bazillion bugs not in the ~14k issues that are on their gnome project page?


Correct according to the search index:

> There are no issues to show.

With the sole exception of one e-mail from legacy Bugzilla:

> This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

That one that HAS been migrated appears as follows:

> You can subscribe and participate further through the new bug through this link to our GitLab instance: …

I mean a bazillion is way larger than 14k.

I would have used "umpteen", sounds large, but it's only in the teens.

Yeah, but that's teens in a base-ump number system.

I realized a while ago that any hyperbolic ('eleventy billion' style, not counting cases where the actual value counts) number only needs to be about 10x the expected value to sound large. Further orders of magnitude don't seem to add any extra emotional impact after that.

that’s not true.

It's a fundamental problem of open source projects hosting on GitHub. I don't think the the Fossil colocation model is necessarily right, but some open protocol is needed so that issues can be easily migrated between these services.

Is it really that hard to write a little script to copy the issues over? Github has an exceptional API.

As others have pointed out, this is Gitlab. When it comes to github, they previously helped me transitioning a bugzilla into github issues, but it doesn't look like they do this anymore.

Back then, I managed to get approval from all our contributors/issue authors so that their individual bugs and comments would show up as their individual bugs and comments, as well as retaining issue numbers.

This is the code for it, if anyone is interested, but as I said the whole thing is unsupported now: https://github.com/jleclanche/bugzilla-to-github

There's an unofficial issue import API:


But it doesn't let you change ownership of issues or comments; everything appears as created by the importing user.

That makes sense. You shouldn't normally be allowed to impersonate another username, which is exactly what a full import does.

Repository owner can edit comments arbitrarily, which already allows for impersonation, although to a lesser extent.

Also, you can impersonate commits freely.

I don't think allowing full import would be a big deal, especially if the UI made it clear that the comments were imported.

With full comment edit history that's no longer the case as much, although you can delete the diffs.

That's the one Github staff helped me use (though there were no public endpoints at the time). I recognize some of this. I don't think it's supported anymore.

They moved from bugzilla to GitLab (not GitHub)

Which one? V3 or V4?

This is gitlab not github

The CADT model strikes again!

All Of this has happened before and will happen again:


Makes me wish I had seen JWZ's writeup before spending so much of my time filing the damned things.

jwz links don't work from Hacker News. They will get redirected.

Though as with sites that refuse entry if I have the adblocker active, I'll take the "if I'm not wanted, I just won't go" option. I doubt I'm missing anything life changing that I can't get elsewhere.

Ooh, I just figured that out. Insidious!

What would be even better is if the HN referrer would create a temporary blacklist for that IP.

Then when you paste a jwz URL into a new tab, he could send a response, "And don't try using a different browser, either!"

Just open it in a incognito window/tab.

only if you set up your browser to voluntarily send the http referrer

Most browsers are maliciously preconfigured to do that out of the proverbial box.

indeed XD

It's not like gnome was utilizing bugzilla anyways. They had one bug that was 11 years old.

The maximum age of a bug in a bug tracker is not really a meaningful metric. All software has bugs, and all large, widely used software has some problems or limitations that no-one is working on. You can close those issues to tidy things up, but that's also a good way to annoy people.

So the only conclusion you can really draw from "one bug was 11 years old" is that they had been using that issue tracker for at least 11 years.

It was a persistent and substantial bug, people jokingly suggested getting it a birthday cake because it was so neglected.

Care to tell us which one it is?

Probably the infamous "thumbnails in file picker" bug that is a meme on 4chan's /g/:



But that's not a bug. It's a feature request

Yes, I'm curious on this too.

The current bug tracker has 40 pages worth of bugs that are more than 11 years old. The oldest one is an 18 year old GIMP bug.

That bug is going to go to college soon.

> The current bug tracker has 40 pages worth of bugs that are more than 11 years old.

No, it does't. The bug tracker might list over 40 pages of reports that were filed over 11 years ago, but that doesn't mean each entry represents a an actual bug.

this will be resolved when systemd-gitlab-gnome-bugmigration-serviced is written. you just need to be more patient and stop thinking in the antiquated ways.

Unrelated, but GitLab has a pretty slick cookie notice. Tells you exactly what they're doing and lets you opt out of non-essentials.

Looks like they use a service called Cookiebot: https://cookiebot.com

I really wish more people would implement cookie notices like theirs. I really like the one that https://www.bosch.us/ uses too.

IMO that should be opt-in, not opt-out.

they're just using cookiebot.com. It's a paid service so might be out of reach for some sites, but it seems affordable and is quite slick. Love that every cookie gets its own explanation.

Are there really people who appreciate these redundant notices? Do you need a notice that a website uses TCP/IP too?

I find these GDPR notices useful. Obviously every website use cookies, but it's nice to know what these cookies actually do. I've already encountered a few news websites listing 100+ advertising/targeting companies whose cookies they use. That was quite eye-opening. I also appreciate all the GDPR emails that landed in my email box recently. I've replied to about every second of them asking for my account/data to be erased.

Apparently, Tumblr shows more than 300 [1]

[1] https://gdprhallofshame.com/22-to-continue-to-use-tumblr-ple...

I can confirm from personal experience. And all of these have to be unchecked separately, there is no deactivate all button. It's completely ridiculous. Oh and your selection isn't restored once you leave the dialog and immediately come back. I know sites have an interest in persuading you to let them share your data, but some of these dark patterns are indistinguishable from black.

The thing is, TCP/IP is necessary to deliver the website. From a user's point of view, a huge majority of the websites have no reason to set a cookie. Anything where I don't login, just read some news, read some blog entries, inform myself about some products, or similar doesn't actually need cookies.

It's just that in recent years the operators of the website have decided they'd like to track and/or analyze their users (best case), or even send that data of to some 3rd party ad network. So I appreciate the heads-up. (Not that it matters, I delete the cookies anyway when I leave the site.)

If you have a site I want to know if you track me or you include third party code that tracks me, I don't care how you do it , inform me and I will decide if I accept or leave.

It's not the notice itself, because that's required by law. It's the fact that it actually gives you information and control beyond "we use cookies, if you don't like it, leave".

When implemented correctly, GDPR notices also give you an option to opt out of targeted ads, something many websites didn't have before, so yeah.

My first instinct upon seeing that intrusive popup was to invoke the element hider from uBlock and nuke it. I don't want to see that noise on this or any other website. Get out of my way and fuck off with the legalese. I'm browsing, I haven't signed any contract, get out of my face.

Nobody wants the notice, but if it's going to be required by law it could at least be useful.

Thought exactly the same, even though removing the "functional" cookies made the cookie appearance re-appear. If the banner requires a cookie I would have expected this cookie to be in the "essential" section.

Sorta a definition problem of essential and functional, you have to sorta-guess what a user might expect.

I’d like it more if it were half the height. And that’s not hard to achieve, by removing the width capping, putting the heading and paragraph inline, removing the logo image and reducing unnecessarily large margins; I got it from what I think was 193px to what I think was 86px, yielding a result that I found much more pleasant.

That is, indeed, _very_ good. I might globally allow JS to load from consent.cookiebot.com for that.

(Just unfortunate that, as far as I'm aware, I can't allow 1st party cookies conditionally on JS from cookiebot being loaded.)

Here's the link to the repos, which was strangely not included in the blog post:


The whole blog post was made to sound like GNOME moved to gitlab.com, so I guess not including the link was intentional.

Mesa is also moving, but they explicitly mentioned it's a locally run instance of Gitlab, not gitlab.com.

It's hosted on freedesktop.org.

The comparison between Phabricator and Gitlab is quite interesting: https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure

Now it's time for them to move to Node.

They currently use the JS engine from Firefox 45 (over 2 years old) and are looking to move to 52 (almost 15 months old). Let's not forget that the update before that was from FF25 which was from 2013.

It's past time to port your stuff to N-API and actually allow devs to have access to standard dev tools using standard dev practices.

It would be a great change for Gnome devs too. Rather than spending weeks of dev time trying to shim in the latest SpiderMonkey version and make sure nothing broke, they could rely on N-API being stable, so they can focus instead on updating the JS interface to ES6+.

I've tried. Multiple times:

https://github.com/gnome/gnode https://github.com/WebReflection/node-gtk https://github.com/endlessm/eos-knowledge-content-node https://github.com/Place1/node-gir

The C++ V8 / Node API is actually more unstable than the equivalent SpiderMonkey one (there is supposed to be NaN, Node's wrapper abstraction library, but complex language bindings like I did requires a lot more than what's in NaN), and overall I encountered a lot of bugs in the ecosystem. Making libuv work with an external message loop like glib requires some complex plumbing. The thread story is a lot worse: glib wants to call your callback function from another thread, and V8 will crash if you try to do that.

There's a lot of edge cases when you're implementing language bindings, and I kept hitting into non-rounded-off edges, bad documentation, and impassable walls.

Have you tried N-APIs? It definitely helps with the documentation issue? What exactly was lacking?


> Firefox 45 (over 2 years old) and are looking to move to 52 (almost 15 months old)

That is quite misleading. They are using the extended support releases: https://www.mozilla.org/en-US/firefox/organizations/

So "almost 15 months old" should be the "most recent one up until the start of this month".

It's actually not that far behind. GJS currently uses mozjs-52. They're working to update to 60 in 3.30 for this fall.

That'd mean even more of the world relying on a monopolist of ecosystem of V8/Blink.

V8/Blink already runs 70% of browsers and a massive amount of software, don't you think at some point it's enough with giving Google control over everything?

Not at all.

N-API was specifically added to make multiple back-ends possible (by removing dependency on the V8 FFI). You can currently use either Chakra or V8. Spidermonkey could be added (there's an outdated spiderNode around) if Mozilla ever got their act together.

EDIT: I really wish Apple would add JSC support to node. It would potentially allow more standard integrations on iOS. Aside from that, JSC is very fast (faster than v8 at quite a few things) and also supports proper tail calls (as specified by the ES6, 7, and 8 specs).

You can use Edge's engine ChakraCore with Node as well.

Why does using V8 or Blink give Google control over your software?

It means one company decides the future direction of the web. (Even more than they already do)

The new gitlab setup is lovely. Browsing the source code and bugs/issues is much more pleasant than it was before. It is giving me an itch to contribute to GNOME somehow.

The actual GitLab instance appears to be at [1], I couldn't find this in the link or the gnome.org announcement.

Good news, though! I am hopeful it can help lower the barrier to entry.

[1] https://gitlab.gnome.org/GNOME

The last time I evaluated GitLab, you needed the paid version to use features that I considered pretty basic, like merge request approvals and multiple code reviewers[1]. I'm wondering now if the GNOME people consider these unnecessary, or if I misunderstood what was possible with self hosting.

[1] https://about.gitlab.com/pricing/

I wonder about the exact same thing. Some time ago I compared the features of GitLab with similar solutions and found that the OSS version is pretty limited. If you want all the nice features for big projects it is more expansive than the Atlassian stack.

If only all of the energy spent on Gnome bashing would be spent on bugfixing, we'd have a perfect Gnome desktop by now. It's sad.

While I agree that excessive GNOME-bashing is unhealthy, one of the problems the critics of GNOME (disclaimer: including me!) have is that GNOME frequently rejects submitted, complete patches, so unfortunately your argument doesn't hold.

GNOME-supporters will probably reply to this that the (main?) reason such patches are rejected is that they go against GNOME's design vision, which is sort-of fair enough, but then conversely, why would you expect people who have different preferences to work on implementing GNOME's vision, which they don't agree with.

Fortunately, there are projects like MATE or Cinnamon which give an outlet for the people who dislike the turn GNOME has taken.

It would be GNOME 98 and consist of a single shutdown button. Perfect feature minimalism and usability. It would also randomly crash when the button is clicked.

Was Github ruled out because it's not free enough in spirit or are the Gnome folks just wanting to run things on-prem?

GNOME and Debian are very committed to free software and Github certainly was always out of contention for them due to being proprietary software.

As discussed on the article, GitLab also wasn't an option for them before the change from a CLA to a DCO. The CLA meant that although gitlab was licensed under a free software license, GitLab Inc. had permission to relicense future versions of GitLab as proprietary software, without needing to obtain permission from the original contributors. This meant that GitLab used to not be sufficiently free "in spirit" for Debian and GNOME. (While this might seem a bit paranoid, Debian and GNOME want to avoid the worst case scenario of GitLab being acquired by a company that isn't as friendly to software freedom.)

All in all, I think GitLab is doing a great job at working together with free software projects like Debian and GNOME and I am sure all the involved parties will greatly benefit from this collaboration.

Thanks, glad to hear you like the job we're doing.

Probably because Github is a closed-source company that can remove you, your repo, or your group at any time, for any reason. Committing to a hosted service is a bad idea (see: Sourceforge). That sort of thing isn't acceptable to a project like Gnome.

To be clear, despite this announcement being posted to gitlab.com (i.e. the "hosted GitLab", which can and will remove you/your/repo any group at any time), the GNOME project is self-hosting their own gitlab instance. So they are indeed insulated from such hypothetical damage.

And will? Are there examples where Gitlab removed users / projects for controversial reasons?

That's not the point. No matter how trustworthy Gitlab seems, The GNOME Project is still more trustworthy.

You'll get no argument on that from me. The way he phrased it though made it sound like this has happened in the past, and I was curious.

I would be shocked if there were not DMCA take-downs that left some people feeling raw - honestly how can you avoid that - but this sort of thing does not attract much notice these days.

Hate to bring up gamergate, but a project related to the movement was completely taken offline by a rogue github employee.

There are a number of sources, all of them biased, so I'd prefer not to link any.

> Probably because Github is a closed-source company that can remove you, your repo, or your group at any time, for any reason.

Any company providing a hosted service can do that, including Gitlab (the company) itself. They chose Gitlab (the product) because they are able to host their own instance (edit: and it’s open-source), that’s all.

Just curious, has this ever happened? Were there any cases where github removed someone's repo?

Yes, WebMConverter. However, I gather the employee responsible is no longer with them.

The C+Equality programming language was removed.

GitHub removed a Shadowsocks library after being targeted by China's great cannon.

PopcornTime I think got removed.

I feel like this is unfortunate. Github has a giant user-based, and using github would be a great way to reduce the friction of having first-time contributors submit a pull-request.

In my case, if KiCAD were hosted on github, I would have already contributed by now.

I think its a shame that more of these projects don't adopt a strategy of "let's try github, and if they screw us over, then we'll migrate to a platform with more freedom".

I think it's shame that lot of projects do. Why?

1.) Compared to Phabricator (which I used for almost last 4 years), github is really behind for code review (I didn't use gitlab, so can't compare). There is lot of missing features: I can't comment on selection of lines, see diff of subset of commits, do stacked pull request (one PR depends on another PR), view of open pull request is chaotic

Effect is that it's way harder to send small PR for review, unless you work on lot of unrelated things and multiplex.

2.) Github dominance is causing everybody using git, and stiffs competition in source control tools. For example, I find mercurial much better than git: it has similar set of features, but it's easier to use, my day-to-day chores I do with single command, and I am much less likely to screw up my repo.

Funnily, I ditched hg the moment it screwed my repo. But even then I was pretty sure git would win, and not for PR reasons.

> In my case, if KiCAD were hosted on github, I would have already contributed by now.

I suppose it's useful never to underestimate the role of culture and tradition when it comes to these things. For the Gnome project, it's probably very important not to rely on a closed-source system, and their developers have a long history of using very different tools anyway.

The barrier doesn't work that way for everyone, either. I "grew" up (programming-wise) before Github. It seems way less cumbersome for me to make changes and submit a patch via email or whatever than to go through Github's fork the repo - do the changes - make a pull request - sync the repos dance.

(Edit: this is especially true for early contributions, or for late and complex contributions, where the review process is a little more, you know, long-winded. Github's review tool is quite atrocious.)

> I think its a shame that more of these projects don't adopt a strategy of "let's try github, and if they screw us over, then we'll migrate to a platform with more freedom".

That's a really risky thing to try. First, moving the entire infrastructure to Gitlab has been a pretty massive undertaking for Gnome -- and Gnome is one of those open source projects that really has resources. Most projects with Gnome's size and history can maybe afford to do that once every seven years, when there's a relatively quiet time and whatnot.

Second, you never really know how that "screw us over" thing is gonna happen. What if the way it happens is that, among other things, when they close your repos or whatever, they cut access to the API for your project? How are you going to migrate to a platform with more freedom then? Copy-paste every bug report ever?

IMHO, 10-15 years from now we'll be really happy that Gnome really understood that "there's no cloud, it's just someone else's computer" thing :-).

Github has dabbled a bit too much in politics in recent years TBH. It doesn't surprise me that projects like GNOME would take pause at that, among the other reasons people are listing.

When my company was evaluating open source cms/hosting solutions, Github was quicky removed from the list of candidates for this very reason. Their criteria for removing software projects was deemed too unstable to depend upon, and the company is too small to garner the same respect from github as bigger companies.

I can’t agree enough.

Possibly more important than any practical implications of GitHub being closed source is the simple fact that relying so intimately on a closed source product would be a really bad look for them, on account of what the first letter in GNOME stands for.

By committing to use GitHub, you’re only really committing to git. git supports multiple remotes for the purposes of mirroring — use that feature.

> you’re only really committing to git

You don't use github just for git.

You use it for issue tracking, pull requests and code review, CI hooks, wiki, github pages, kanban boards, bot integration, and so on.

That's all stuff that locks you in to Github, and is non-trivial to migrate to another provider.

It’s a given that the more GitHub features you use, the more difficult it is to move away from GitHub. It’s also a given that you can reasonably limit the extent to which you use GitHub and thereby limit the difficulty in transitioning to another solution.

The idea that it’s GitHub locking you in rather than you locking yourself in to GitHub is the argument I take issue with. But no quarrel at all with Gnome choosing GitLab, because GitLab is genuinely great.

The whole reason GNOME wanted to switch is because they wanted to have all the extra features (issues, etc) in a single place, as is provided by Github and Gitlab. Their old cgit interface already did a good job at hosting their git repositories.

> "You don't use github just for git."

Well, some people do. I don't, apparently you don't, probably most people don't. But you could and some people do. I've seen a few projects on github with notes to the effect of "don't bother submitting issues/PRs here, do it through our [mailing list/etc]"

The Linux kernel for example.

The kernel is just mirrored on GH, which is why they want PRs and bug reports sent to their mailing list.

And, with a whiff of irony, git itself.

Why is this ironic? Git predates github.

It's logical of course, but I see the irony. Or maybe it's not irony, nobody really knows what irony is, but it's mildly.. amusing? It makes half my face smile in a manner similar to but not quite like a smirk.

Is the Git project expected to uproot themselves and go chasing Github or Gitlab or Gogs or whatever else is fashionable?

Definitely not 'expected'. I like the mailing list bug tracking more than having that on git{hub,lab,whatever}.

git makes it even possible to host a repo on multiple git* hostings, but apparently nobody came up with a successful distributed pullreq/issue tracker yet.

Of course not.

Or Git itself

> By committing to use GitHub, you're only really committing to git.

Make sure you also tell your users not to use GitHub's comments, issue tracking, pull requests, release system, favorites/watches, or authentication.

So you're suggesting that the new home for the GNOME project's code be GitHub, without the GitHub.

Issue tracking is optional, if you disable it users wont be able to fill issues. You can easily ignore release system (by not using it) and I am not sure what you mean by authentication. As for pull requests, it is reasonable to expect contributors to submit them wherever your readme points to.

I don't mean to say that gnome should use github, I think that it is overall better if there is no single dominating company for open source. Just that organizing so that github is git hosting only is not that hard.

The whole point of the migration was to consolidate things to make onboarding new contributors easier. If they only used the git part of github, it would be little better than their existing cgit setup.

I don’t understand where in that comment you believe I suggested that the Gnome team should have chosen GitHub. Most likely because I made no suggestion.

Please try to be more careful with how you approach reading comments.

Gnome is already being mirrored to Github. You can do your pulls from there.

Meanwhile, they want to use the bug tracker and other features too.

"GitHub is not Free Software, of course, which makes it unacceptable to many in the GNOME community."

Only "many"? o_O ;-)

In the dark prehistory of the Linux desktop, Qt/KDE was GPL so Gtk/GNOME went with the "more free" LGPL to support proprietary apps. I guess that strain of pragmatism hasn't gone away.

It's the other way around -- Qt wasn't GPL until 2005, GNOME started in 1997 in response to the non-free license.


Ah, right, Qt wasn't GPL but it still "infected" apps with a copyleft-like provision.

It's not massively important, but I still think it's a good idea not to make a conclusion and then work your way back through history viewing with that lens.

GNOME was (and is as far as I know) part of GNU. The G stands for GNU -- GNU Network Object Model Environment. It actually had a CORBA ORB in it. Apart from the misguided idea of building a DE around CORBA (which, I admit, I thought was a fantastic idea at the time), the main reason for doing the work was that KDE was built on top of QT. KDE was GPL and everybody was completely happy with that part of it. The problem was that it was built on top of something that the FSF felt was incompatible with the GPL (I can't remember the exact issue).

GNOME uses the LGPL for its libraries and the GPL for its applications -- as per virtually every normal FSF project. One of the reasons there were more libraries in GNOME than you might ordinarily have was because it was intended to be a set of distributed components all talking together over TCP/IP. It's an enormous mistake, but as I am fond of saying, we're all young once.

Anyway, the point is that your notion that GNOME was somehow more pragmatic in terms of trying to avoid copyleft licenses is completely incorrect.

You can run Github on prem using Github Enterprise [1]. However, that follows a subscription model and Github can potentially terminate it at any time.

Gitlab has an open source version [2], which means that preferring Gitlab over Github prevents giving more control of the project's direction to another entity. ( Not speaking on behalf of GNOME of course, just remarking that it is a good thing that free software projects are preferring Gitlab over Github )

[1] https://enterprise.github.com/faq

[2] https://about.gitlab.com/installation/ce-or-ee/

Also you are not allowed to use GitHub Enterprise in the "public facing internet" without "Private Mode" which means only people with an account on the system can access that.



This is very annoying because I can no longer see the list of bugs I filed against GNOME products. They are all owned by 'bugzilla-migration', not me!

[additional] I appear to be subscribed to the issues that I filed in Bugzilla and were migrated to GitLab, but there's no way to get a list of all the issues I'm subscribed to: https://gitlab.com/gitlab-org/gitlab-ce/issues/12697

Fantastic news!

Highly unrelated (and lots of reasons missing): I was never a fan of Gnome and for years ended up "just going with LXDE instead" until I gave Budgie a try about 6 months ago. I have never been happier in my life.

Where was it before?

>Before migrating, GNOME used a broad range of tools to fulfil a number of specific purposes – from CGit for hosting to Bugzilla for bug tracking – but the number of tools made the onboarding experience for new contributors cumbersome and confusing. They started looking for a single tool to meet more of their needs to make this process easier and to improve their own workflows.


...did they just delete all the old bug reports?

"Before migrating, GNOME used a broad range of tools to fulfill a number of specific purposes – from CGit for hosting to Bugzilla for bug tracking"


it feels so slow to browse anything on this gitlab...


So, I'm really curious about this. Is it a rampant spam-bot that blew its load too early in the wrong thread? What happened here lol

I'm waiting for Mesa to move to Gitlab too.

Slightly related, Does anyone have a virtual machine image of Ghome-Development environment that I can use straight away. I am on a corporate RHEL 6 machine, so it has been very tough to be able to get the development environment up and running there.

I am not even able to mame changes to gnome-terminator 1XX version because of this.

GNOME Builder is set up to use flatpacks to be able to develop on the latest software versions. The newcomer guide has instructions for how to set this up:


I never used it on RHEL 6 though.

Just curious why doesn't your company upgrade to RHEL 7?

> Carlson proved in 1938 that this process was viable, using moss spores for toner. But when he pitched it to Kodak, General Electric Co., and other tech giants of the day, the response was, as he later put it, “an enthusiastic lack of interest.”

Another story where the inventor goes to big companies to sell the product and they dont take him seriously which is kind of funny when Xerox became a big corp, it did not take the GUI/Ethernet created by their people seriously.

Too bad GitHub was out of the question just because it's not open source. I don't think there is a single platform out there that has done more for the open source community than GitHub. Most of the great OSS projects are on it and it helped democratize open source participation by providing a very nice UI and a set of robust tools that simply didn't exist before.

On the other hand Github could also become the next sourceforge.

Sourceforge went the way it did not only because it was always a hornet's nest of ads and viruses, but they allowed bloatware and viruses to be bundled with project downloads. I don't see GitHub ever behaving in that way, though if they did there'd be a mass exodus for sure.

GitLab too, but granted, if you host your own version, you wouldn't lose anything.

That being said, GitHub has almost no choice to keep being a good guy with the OSS community. If they lose it, they lose the respect of the developers, and they would lose their paid customers in the process.

Another point for Gitlab is that it can be forked if the parent company goes bad (e.g libreoffice and oracle). When looking at it with this perspective, widely-used essential projects can live and thrive from one party to the next.

GNOME is a free software project (as self-described[0]) not merely an "open source" project. Therefore, while GitHub's place in the "open source" ecosystem and its contributions to said ecosystem are well known (and worthy of respect), it does not share in the principles of the free software community. GNOME, as a free software project (and a subproject of GNU at least nominally[1]), is inclined to select an option in line with its principles.

[0] https://www.gnome.org/about/

[1] https://www.gnu.org/software/software.html

Why should github be the first choice and subject to exhaustion? Are there not compelling reasons to got with gitlab?

GitLab is a great first choice. I’ve been using it for 6+ years, heavily in the last 2, and it’s feature set is fantastic. Now I’m getting into the Auto DevOps features and it’s been a great experience.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact