Gnome has moved to GitLab
about.gitlab.com
about.gitlab.com
… though I am pretty sure they left the bugs in the source intact.
(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.
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".
(edit: I didn't see it was already posted below)
If it's closed for "inactivity" while I'm actively waiting for a response from the developer, that's going to annoy me.
There's a quick and easy way to tell if someone is actively waiting: respond to them.
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?
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.
> 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.
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.
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).
Why not have a buck tracking system where only contributors have write access and a second system where users can submit their reports?
In the face of that reality, a separated internal and external bug trabkin system might be a viable solution.
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.
A quite safe value from there is
network.http.referer.XOriginPolicy = 1
All the more reason not to undo the work of its contributors.
> 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: …
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
https://gist.github.com/jonmagic/5282384165e0f86ef105
But it doesn't let you change ownership of issues or comments; everything appears as created by the importing user.
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.
https://www.jwz.org/doc/cadt.html
Makes me wish I had seen JWZ's writeup before spending so much of my time filing the damned things.
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!"
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.
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.
[1] https://gdprhallofshame.com/22-to-continue-to-use-tumblr-ple...
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.)
(Just unfortunate that, as far as I'm aware, I can't allow 1st party cookies conditionally on JS from cookiebot being loaded.)
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+.
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.
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".
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?
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).
Good news, though! I am hopeful it can help lower the barrier to entry.
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.
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.
There are a number of sources, all of them biased, so I'd prefer not to link any.
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.
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".
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.
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 :-).
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.
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.
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]"
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.
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.
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.
Please try to be more careful with how you approach reading comments.
Meanwhile, they want to use the bug tracker and other features too.
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.
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 )
[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
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure...
I am not even able to mame changes to gnome-terminator 1XX version because of this.
https://wiki.gnome.org/Newcomers
I never used it on RHEL 6 though.
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.
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.