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".
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.
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.
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.
> 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?
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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".
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.
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.
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.
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+.
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'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?
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).
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 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.
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.
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.
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.
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.
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.
> 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.
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".
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.
> 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.
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.
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.
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]"
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.
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.
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.
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 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 )
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
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.
>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.
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:
> 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.
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.
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.
… though I am pretty sure they left the bugs in the source intact.