Great news :) We switched to Gitlab at Arch Linux recently as well: https://gitlab.archlinux.org/ (well, we're still migrating projects and users, it's a long process)
Does this mean no more Flyspray? I really hope so.
Xfce switches to GitLab
111–120 of 148 posts
Re: Xfce switches to GitLab
#112Earlier quoted context omitted.
Honestly you don't need any particular skills to install Arch. Just time and access to the instructions. It's a neat way to spend an afternoon once, but I just switched to Manjaro too on future installations,
I loved Arch until I figured out their security patch intervals are like a week behind upstream..
That is sadly what you get with an non-commercial all-volunteer distribution. We only have so much time on our hands and Security Team members are productive members of the community holding several roles.
More contributors are always needed and welcome.
Re: Xfce switches to GitLab
#113Earlier quoted context omitted.
.
This past year, on my Thinkpad P50, I've switched between Ubuntu, Fedora, and Arch; Arch has by far been the least buggy. With Ubuntu, things would go haywire when docking/undocking. With Fedora, putting it to sleep was always a risk because after putting it to sleep I would sometimes I would open up my laptop to a black screen that I couldn't recover from. I was fine with that and just wouldn't put my laptop to slee…
Could it simply be due to the difference in kernel versions?
E.g. you have some new-ish hardware where the most recent kernel (packaged in Arch) includes fixes.
Re: Xfce switches to GitLab
#114> Please poke us on IRC or the mailinglist if you’re lacking repository access or ownership. (By default new users cannot fork before being manually approved. Yes. We are afraid of the spambots.) Do forks introduce potential PR spam or something of that sort on GitLab?
I help manage a Gitlab instance for a FOSS project with around 800 users, and we had spammers post spam on personal repos 3-4 times in the past 2 years. It can be hard to catch (I keep an eye on the latest new projects).
Re: Xfce switches to GitLab
#115Earlier quoted context omitted.
GitHub does this too, and it's awful. Why would anyone want to skip reviewing the biggest changes?
I have developed a habit of going through my own pull requests immediately after opening them, and adding a "don't forget this file" comment to all the ones that get collapsed. 'Cuz yeah, I've seen some nasty stuff sail past code review simply because it's so easy to accientally miss those files.
Good one, I'm going to do that too, thanks. It's pretty nuts how broken a UI is that it forces us to do stuff like this though.
I feel like everything about the GitHub PR UI is targeted at reducing the code review job to being a human style checker. Minimal context, no code navigation, abysmal rename following.. it's really hard to review the design of a change.
Re: Xfce switches to GitLab
#116Earlier quoted context omitted.
This past year, on my Thinkpad P50, I've switched between Ubuntu, Fedora, and Arch; Arch has by far been the least buggy. With Ubuntu, things would go haywire when docking/undocking. With Fedora, putting it to sleep was always a risk because after putting it to sleep I would sometimes I would open up my laptop to a black screen that I couldn't recover from. I was fine with that and just wouldn't put my laptop to slee…
This fragmentation between what works on what dists makes me sad. Philosophically I've always admired BSD for the consistency, considering how there's just 3-ish of them, realistically I'm a Manjaro user as I don't have enough Linux-fu to set Arch up.
Long ago I decided to use Debian STABLE with Gnome. There is no fuss. There are no surprises. You just get back to work and (the infrequent) upgrades don't break.
There are some apps which I have to install outside the regular repositories (RStudio, Google Chrome, Zoom, etc.) but they all provide binaries specifically for Debian, and it seems this is becoming more commonplace. I recently installed Mattermost for a client on Debian Stable, and it was trivial given their provided binary and instructions. Time is valuable, folks.
Re: Xfce switches to GitLab
#117Earlier quoted context omitted.
Honestly you don't need any particular skills to install Arch. Just time and access to the instructions. It's a neat way to spend an afternoon once, but I just switched to Manjaro too on future installations,
Manjaro Architect's installer is really neat btw.
+1 for Manjaro. I greatly enjoyed using that for a time on one of my tinkering systems.
Re: Xfce switches to GitLab
#118I'll be forever grateful for what GitHub has done for the OSS community. People today don't remember what they replaced, namely Sourceforge and various home-grown tools of various levels of dysfunction. Would anyone doubt that open source contributions, and individual contributers even more so, have grown by an order of magnitude or more in the last decade or so? And that GitHub's process improvements and standardisa…
GitHub wasn't the only service responsible for replacing Sourceforge. Lots of open source projects used to be hosted on Bitbucket before Git gained total domination among the version control systems.
Re: Xfce switches to GitLab
#119Earlier quoted context omitted.
Couldn't find the feature today when doing a large review. Do you have to enable it somewhere?
In the top left, there should be a "changes from..." drop down menu that will let you choose which commits you want to view. The default is "changes from all commits". If you're on GitHub Enterprise, availability will depend on the last time your company has installed updates.
that features has been in bitbucket for ages
Re: Xfce switches to GitLab
#120Earlier quoted context omitted.
Couldn't find the feature today when doing a large review. Do you have to enable it somewhere?
In the top left, there should be a "changes from..." drop down menu that will let you choose which commits you want to view. The default is "changes from all commits". If you're on GitHub Enterprise, availability will depend on the last time your company has installed updates.
That is not the same feature.
It requires you to always add your fix in a new commit add opposed to amending the commits and maintain a clear purposed commit list.