… 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".
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?
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: …
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.
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.
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.
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".
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 )
(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).
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.
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure...
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.
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.
Good news, though! I am hopeful it can help lower the barrier to entry.
[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
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.
