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.
Gnome has moved to GitLab
131–140 of 212 posts
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…
Re: Gnome has moved to GitLab
#133Too 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.
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…
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
#135Earlier 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)
Re: Gnome has moved to GitLab
#136Earlier 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.
Re: Gnome has moved to GitLab
#137Earlier 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.
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
#138Earlier 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.
Re: Gnome has moved to GitLab
#139Earlier quoted context omitted.
"GitHub is not Free Software, of course, which makes it unacceptable to many in the GNOME community."
Only "many"? o_O ;-)
Re: Gnome has moved to GitLab
#140Earlier 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…
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.