Live data from Hacker News

Gnome has moved to GitLab

about.gitlab.com

131–140 of 212 posts

Re: Gnome has moved to GitLab

#131

Earlier quoted context omitted.

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

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.

Re: Gnome has moved to GitLab

#132

… 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 bug…

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)

Re: Gnome has moved to GitLab

#133

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.

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

Re: Gnome has moved to GitLab

#134

… 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 bug…

> 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?

Re: Gnome has moved to GitLab

#135
post #132

Earlier quoted context omitted.

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 bug…

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)

It did not omit the referrer for me.

Re: Gnome has moved to GitLab

#136
post #130

Earlier quoted context omitted.

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…

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.

Re: Gnome has moved to GitLab

#137
post #42

Earlier quoted context omitted.

All Of this has happened before and will happen again: 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.

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

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!"

Re: Gnome has moved to GitLab

#138
post #135
post #132

Earlier quoted context omitted.

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)

It did not omit the referrer for me.

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

Re: Gnome has moved to GitLab

#139
post #123
post #18

Earlier quoted context omitted.

"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.

Re: Gnome has moved to GitLab

#140

Earlier quoted context omitted.

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 bug…

> 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 diff…

> 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.

Post reply on HN