A proposal to move Gnome to GitLab
lwn.net
lwn.net
They upgrade every week. Who the hell does that to paying customers? And half of their website functionality doesn't work when they upgrade -- but their upgrade-banner always says "no down time is expected". It is a running joke in my company.
We constantly get error 500 during upgrades. Merge requests don't commit. Rebase feature didn't work till a few weeks back. Gitlab runners get stuck every now and then. I use it everyday because of company policy, but folks, Gitlab is a really poor product. Feels like they test their product on paying customers.
Also, do they even know how good their competition is at? You can't see the what is changed in response to your comment between two MR uploads. You can't add comments on unchanged parts of the code in the diff-view. You can't add comments when you view the diff between two uploads of an MR. My list of complaints is endless.
Not at all.
Some gripes:
- Bad UX, just one example: many things that require one-click + type in competetitors products require more than one click (2-3). Another: Hard to see in the issue tracker which issues were updated.
- Bad notifications: It seriously creates notifications for actions done by oneself. That makes absolutely no sense at all whatsoever.
- Somewhat sluggish performance .... compared to Github!
- Poor review UX
- Annoyingly bad issue listings (e.g. select some issues and change something about them)
... and I've literally only used it in one rather small project. Incidentally no one of the regular users I know are satisfied or ok with Gitlab.
Ironically I wish this feature existed on Github (does it???). To be more specific, I wish I could get emailed when I make comments on PRs. As crazy as it sounds, it is much easier for me to track whether the comments have been addressed in a list of emails instead of trying to dig through Github's comment interface after I've made many different comments.
Of course this wouldn't be necessary if that compact list just existed in Github already...
- Go to https://github.com/settings/notifications
- Check "Email" under Watching
- Then check "Include your own updates" in the section below
It's extremely useful to be able to read whole threads on email when you have a potent MUA.
- We're working on improving the UX. Issue filters allow you to type now. UX team work can be seen in https://docs.google.com/presentation/d/163xL_FLQLsWD8Yv9GfkR... and https://www.youtube.com/watch?v=NtDzyHnedoE The UX research in https://docs.google.com/presentation/d/1ZE9BNAnIPDKxgSyQU5su... and https://www.youtube.com/watch?v=k8-Jto8FTmA Sorry for the general answer, I can't be more specific since I don't know what flow you mean.
- As mentioned in https://news.ycombinator.com/item?id=14354087 some people like getting their own notifications, but maybe we should make it configurable.
- GitLab.com is slow compared to GitHub.com, we're working on this in https://gitlab.com/gitlab-com/infrastructure/issues/947 The GNOME team is looking to self host so they don't have this problem.
- What is the nr. 1 thing you would improve in the review UX? I'm excited about https://gitlab.com/gitlab-org/gitlab-ee/issues/1984
- I think mass updates to issues are getting some love in https://gitlab.com/gitlab-org/gitlab-ce/issues/28340
Everything else requires maintaining more pieces of infrastructure and is not integrated so nicely.
I agree that Gitlab is far from perfect, but it's the best solution in this space IMO.
The ability to view build reports, such as test results and the like.
Tracked many times, in various forms: https://gitlab.com/gitlab-org/gitlab-ce/issues/13227 (73 votes), https://gitlab.com/gitlab-org/gitlab-ce/issues/18664 (67 votes), https://gitlab.com/gitlab-org/gitlab-ce/issues/10982 (53 votes), https://gitlab.com/gitlab-org/gitlab-ce/issues/17081 (22 votes), https://gitlab.com/gitlab-org/gitlab-ce/issues/23618 (a mere 5 votes).
But having to stop working on the thing you're building in order to learn someone else's toolchain, build a fix and (and this is key) persuade another organization that a fix is valuable is incredibly expensive.
I've fallen in this trap more times than I dare to count.
Overall, I am very grateful that gitlab exists but gitlab.com does make me feel like gitlab over all is a slow piece of software.
The only Enterprise Edition feature that is under discussion is merging without creating a merge commit. We're considering to open source this to make this move work.
GitLab.com still feels slow but running an instance specifically for GNOME should be fast.
I believe it all started when they got a bad rap for doing unspeakable things like supporting minorities to get into the industry, plus one actually wrong decision by a customer service rep approving a complaint about some word in some repository that could be offensive, but clearly wasn't in the context.
Next followed about a month of constant griping about how awful github is, followed by many many features being released which had been in the pipeline all along.
Meanwhile, everybody on HN was trying to find an alternative. Since going back to Sourceforge would have demonstrated slightly-to-obviously that Github was among the best things that ever happened to OSS, the heavy-hitters moved all their projects to Gitlab, which was a third-rate clone of Github at the time, and may or may not have advanced to second-rate since.
Those two projects are, apparently, really enjoying GL.
We always run the latest version of GitLab on GitLab.com and we’re working on making (almost) all our deploys downtime free (Issue: [3], MR: [4]). Of course, you can opt to self-host GitLab. It’s easy and quick to setup and requires very little maintenance via our omnibus package [5], and of course, we're here to help you if you get stuck along the way.
[1] - https://gitlab.com/gitlab-org/gitaly
[2] - https://gitlab.com/gitlab-com/infrastructure/issues/?scope=a...
[3] - https://gitlab.com/gitlab-org/gitlab-ce/issues/26130
[4] - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9976
As far as the frequent upgrades go, we've been using .com as a way of dogfooding GitLab at scale. Sometimes this goes well and other times it doesn't. We're actively working to improve this process so that downtime and breaking changes are less frequent. The end goal is to eradicate both issues so that upgrades are seamless.
Whats up with that?
As someone who hacks on a SaaS with a sprawling feature set which ships often, I understand where you're coming from. But I would recommend giving things like that some thought.
A sign of the future. As browser march headlong into being app platforms instead of browsers expect the back button to disappear entirely.
Why the X-Requested-With should be in Vary when the same client did the request? (Yes, I see, Ajax libs populate this field, whereas usual browser navigation doesn't. Makes no sense.)
Why is that resource in cache anyhow, when it should be Cache-Control: no-cache (or at least must-revalidate, but it probably is, but of course that again means that the cache returns the JSON after getting the 304 from the backend, because it doesn't differentiate between responses with different Content-Type)?
It seems to me that the X-Requested-With is again a hack on top of "representational state transfer", because it was easier than trying to use Content-Type.
Simplicity. Ruby on Rails facilitates that approach, for example.
> And in that case should the Content-Type (or Accepts) be the main factor?
Content-Type, yup! Unfortunately Chrome and IE 10 (not sure about Edge) disagree on that.
Without the Vary header, the back button leads to rendering what the server last returned, without taking the Content-Type into account - which is completely nonsensical in my opinion.
Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=94369
Repo and page that demonstrate the issue: https://github.com/guilhermesimoes/chrome-bug
This has been going on since at least 2011 so it seems nobody cares.
I honestly do not understand why that Vary header is necessary.
Firefox doesn't seem to need it to render pages from its cache correctly.
> History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.
Doesn't matter whether a Vary header is sent or not; when a user clicks the back button they should see exactly what they saw when they previously viewed that page; regardless of whether that content is cached or not.
Because they are the same underlying thing...
I mean, I know RoR likes magic very much, but it's not totally surprising to separate the backend from the frontend.
And then use a SPA framework and use Ajax to communicate with the backend via a "REST API", because that simplifies the backend. A lot. You don't have to have views, templates, and so on implemented.
So either the REST API is not a REST API, but a lot of interesting endpoints for the frontend dynamic JS magic, or the frontend is not a frontend, just a lot of glitter thrown up on a REST API.
(I quickly tried to get something in JSON from a GitLab URL, but I just get a HTTP 406. :( )
no it isn't?
@Perihelion: Allow me to be the one who says "thanks for your efforts" and "keep up the good work".
My team are using GitLab to manage development and we're happy with how it's going so far.
I feel that way about Gitlab -- so many people want Gitlab to replace Github, but I can't understand why. "Let's replace product A with product B because Y Combinator." I'm just not sold. If Gitlab were 10x better, then maybe I'd get it, but it's not.
users who don't pay for things.
I completely agree. I only use it because it has a CI for private projects for free but that's literally the only reason. The UX is not great (Github PRs are light years ahead of Gitlab merge requests), the overall UI is confusing and is hard to find stuff you want to, it is still extremely slow and lots of downtimes. They have some good ideas but the execution is usually not great.
The only 2 selling points are the free CI and the fact that is open-source but overall I think Gitlab wouldn't be a hard competitor to beat for newcomers.
I would love to know more about your thoughts on this statement ;) in order to get to actionable issues on which we can improve!
- Can see new stuff that happened since the last time I was on the PR
- Review mode
- Faster
- Can view rendered file (like .md) without leaving the page
- Commits visible on the main tab
And for a more subjective one: the gitlab feels extremely crowded and a general lack of polish.
Take the right sidebar on a merge request for examples, they are icons since it is hidden by default even in full screen. Hovering on the + shows a Add Todo dialog but hovering over any other icon does nothing. I had to click to see what the watch and stopwatch were. In general, I wasn't able to guess what any of the icons were, except for the labels icon. On the other hand, Github doesn't use icons: just a bunch of text which is imo nicer in terms of design and more user friendly.
Thanks for leaving some feedback.
* Speed
GNOME is looking to self-host their own GitLab CE instance. We understand that GitLab.com might have some performance issues. This is specific to our hosted GitLab instance due to its scale. A self-hosted instance on a much smaller scale is much much faster.
Also, we're always looking to improve GitLab performance - check out issues labeled "performance" in the GitLab CE repo [1] as well as issues in the infrastructure repo which are about .com specifically [2]
* Commits visible on the main tab
A list of commits is just a click away in the MR view, in the "Commits" tab. Also commits that are added are also displayed in the main tab.
* Can see new stuff that happened
The main MR tab lists the actions that happened related to it in a chronological order, from first to last. You can always look at that and see any new MR changes
* Sidebar
The sidebar is expanded by default on larger screen sizes and collapsed on smaller ones to preserve screen real estate for the MR itself.
I opened an issue about the icons themselves, see [3]
* View rendered files in MR
We have renderers for all kinds of files. But in a MR, we diff the MD source files. If we rendered them, diffing them would be almost impossible.
I opened an issue about having toggle-able rendering in the changes tab in MRs. Feel free to chime in in [4]
* Review mode
Could you explain this in a bit more detail? Maybe we could open a feature proposal for this functionality.
Hopefully I addressed all your concerns, feel free to add anything or dive into any of the issues, or even contact me personally.
[1] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
[2] - https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...
This mean they will have full control of the update process, right?
If you have any specific complaints or issues. We'd love to hear about them so we can improve.
We've logged countless UX regression issues on their issue tracker and each one has taken 9 - 12 months to fix. Meanwhile, they keep churning out new features that we don't use.
I wish they'd just stop adding new features and spend 6 months fixing their UX and improving stability + performance.
Another data point: I've reported quite a number of issues, all of them have been triaged real quick, and many have been swiftly handled (the last couple were dealt with within a week). The longer ones are mainly larger scope (or depend on one thereof), or - wait for it - adding features.
> I wish they'd just stop adding new features
Every release brings a couple of features that we really enjoy having though, there's a balance to be had. BTW we're self-hosting and performance as well as reliability has been excellent. (disclaimer: happy EE customers).
I only have some gripes in the UX/UI:
- On GitHub i find the layout / navigation pretty clear. It's a bit hard to explain this feeling, but the information is always well packaged and that makes it easier to grasp (whether we're talking about commit, issues, reviews and whatnot).
- GitLab has definitely improved (even though it's not that nice that you upgrade and everything moves) but still with their layout (probably using too much % of the screen?) i always am confused. I feel there's "too much information" on the screen and that makes it hard to understand where I am and what I am doing.
But I really really love GitLab Pipelines: we use it pretty much as it was intended (CI using Docker images on a runner, manual tasks for deployments, etc.). And it simplifies a LOT our devops.
https://gitlab.com/gitlab-org/ux-research/issues/7
I would love for you to take a look and give us feedback on the two directions we are considering. When we made a significant change to our navigation by removing the sidebar, most felt that there was "too little" information being shown, so I am intrigued by your "too much" comment.
> You can't add comments on unchanged parts of the code in the diff-view.
Please join the discussion at https://gitlab.com/gitlab-org/gitlab-ce/issues/26722 and https://gitlab.com/gitlab-org/gitlab-ce/issues/14396
> You can't see the what is changed in response to your comment between two MR uploads.
and
> You can't add comments when you view the diff between two uploads of an MR. My list of complaints is endless.
For the following issues I created these gitlab issues to start the conversation. Internally and on the issue there may be a reference to already existing issues covering these subjects.
Thanks for your feedback! You can always join the conversation and/or contribute in order to get things like this shipped faster!
See: https://gitlab.com/gitlab-org/gitlab-ce/issues/32399 and https://gitlab.com/gitlab-org/gitlab-ce/issues/32400
On the left I see the old MR and my comments on that upload and on the right I see the new diff around the commented lines.
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10388
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10572
Not as active in GNOME these days, so my vote is not really a vote... but I do have my own reservations about both "Git-Wrapped" solutions, especially if they start requiring pull requests.
Splinter/Bugzilla is definitely not a long-term code review solution though, so something really has to give there.
I submitted my first patch to Cairo a few weeks back and depressingly it was met with tumbleweed. I tried contacting people on irc but again, nothing.
In contrast I submitted my first patch to fontforge recently too (GitHub) - it was merged in a couple of hours.
Developer interaction matters and I know plenty of open source devs who have put in a lot of good work are going to hate me for saying this - but those old platforms you're using suck for fostering community contributions. (And I thought the code quality in Cairo was great - I bet if it was on GitHub there would be loads more activity)
There used to be a time (from what I've read) when free software meant a tarball available for download every n years. Apparently, Open Office under Sun was very good at not accepting patches at all.
Things are looking up though. Please don't give up. Look at the comments on previously on hn https://news.ycombinator.com/item?id=14051106
Now, we have things like KDE Neon with git-unstable and git-stable which basically allow end users to participate in the latest changes in KDE and now the windows/meta/super key actually does something in KDE which I wouldn't know if I was on Kubuntu.
So you can bind a menu, or an application launcher, such as the start menu, or app dash, to Super.
You might want to try shooting Bryce Harrington an email directly to see if he can review your patches. Good luck.
Sounds like the Skia team has all the talents and is very well funded, so I'm a little surprised that it failed to catch on (outside of Google).
Edit: Servo has rust bindings for it, so they might also be using it.
[1]: https://www.gnu.org/software/repo-criteria-evaluation.en.htm...
https://gitlab.com/gitlab-org/gitlab-ce/issues/15678
More discussion can be found in the archives:
Over the last few weeks I've started to trial Phabricator, using the hosted Phacility.com service. I haven't actively migrated any code yet, but just using Phabricator to manage some workflow elements is a much enhanced experience. Phabricator's Maniphest (tasks, issues) and Project Workboards feel much more intuitive than GitLab's. The Kanban board on GitLab drives me insane with the amount of clicks I need to do things, small glitches with tags and lack of a single unified multi-project view. Perhaps I haven't used Phabricator enough yet to hit such little frustrations.
The point is, I'm probably going to migrate all my personal work over to Phacility.com and if things continue to move smoothly recommend using Phabricator at work, mostly for their workflow and project management tools.
I should make it clear that as a developer, I'm just messing about for my own interest. Professionally, I'm a project/product manager with a small team of developers and scientists. I wanted to try and standardise on a single tool to manage workflow, while still staying out of the developers' way while they did the important stuff of building the product.
Also, does it have a CI facility?
I haven't looked into CI with Phabricator, and this could be a killer for a move away from GitLab if it's not available.
[1] https://secure.phabricator.com/book/phabricator/article/diff...
[1] https://secure.phabricator.com/book/phabricator/article/harb...
GitLab was ok but in retrospect the forking model with merge requests was cumbersome in our corporate environment. The way Phabricator works makes much more sense and the "arc" tool manages all the complex stuff like feature branch handling with automatic master rebase and branch deletion etc.
Phabricator has an excellent code review workflow... far superior to what GitLab offered back in September.
Sure, Phabricator internally uses patch sets and you have to install and use an additional tool "arc". But git without any additional tooling support just doesn't give you a nice code review experience IMHO. "arc" is filling the gap. And you have to know just two commands: "arc diff" to create a new code review or update an existing one and "arc land" do merge an accepted code review into master. The rest is vanilla git.
I highly suggest anyone to try Phabricator and its code review feature. Great, pragmatic open source software.
There must be more to this. GitLab CE does support LDAP authentication. It's been configured and operating on our corporate GitLab CE server for over a year.
Maybe they needed more advanced features like group membership sync? [0] For basic user authentication LDAP + GitLab CE works great.
They also offer Mattermost integration, which means you can authenticate to Mattermost using LDAP, which would otherwise be a paid feature. [1]
[0] https://docs.gitlab.com/ce/administration/auth/ldap.html
Don't understand the hate here for GitLab. It's a rapidly developing product, so yeah, it's got some rough edges. But my experience with it has been hugely positive, and I much prefer it over GitHub for a number of reasons. Integrated CI is a huge plus; for instance, I've set up a project that runs a static site generator after each merge to prod. This is certainly possible with other tools, but I'd rather have a one-stop shop. (This is why I also like Visual Studio Online, at least for professional work.)
Even if you're a die-hard GitHub fan, you have to acknowledge that some competition in this space is healthy. We don't need a repeat of the Sourceforge debacle. Centralization is dangerous.
I was hoping these comments could be about the benefits that could be had by gnome from enabling dev access through gitlab.
If you have issues with that one project you worked on with gitlab, please contact Gitlab and let them know, as they are very open and responsive and willing to work with you, but this is not the place to change the topic from gnome to complaining about that one project you worked on two years ago and why gitlab sucks even though you never took the effort to submit a ticket with gitlab to fix it
You see, github is not just a fantastic plateform, well crafted and reliable, to use git. The important part in the name is "hub".
Everybody is on github, have a github account, nows how to use it. It removes a lot of friction.
Now I know it's proprietary. And it's close source. But since their track record as a company is exemplary, and since you can easily backup the data in there anyway, not being on github is like refusing to put shoes for a marathon because your feet will breathe better.
Also, a lot of GNOME developers are strong on ethical side of open-source therefore they would never feel comfortable hosting something on closed platform.
GitLab is great choice because it's:
- Open Source
- Self Hosted
- Free (Unless you are going Enterprise)
Yes, the UI sucks and there was this database fiasco. However since it is open-source it is improving and adding new features 10x faster then GitHub.
Except for issue/project tracking. And all ACL and organisation configuration. And CI hooks and so on. Of course GitLab lets you make a clone of this information, but that's a hack.
Also please note that neither GNU nor the FSF really care about new fads. Their main concern is software freedom, and much like the whole convenience-security tradeoff there is a freedom-convenience tradeoff too. The FSF and GNU project do not compromise on freedom.
[1]: https://www.gnu.org/software/repo-criteria-evaluation.en.htm...
So what you can do is:
- create a git lab instance as a synchronized unused backup that doesn't require a lot of maintenance to work.
- use github as the main dev plateform.
- then if (and it's a biiiiiig if) something ever go wrong, you switch
The benefits are huge :
- much less work work for the GNU and FSF;
- much more reliable plateform. If you get hit by a massive traffic, your gitlab instance is less likely to hold than github;
- much more visibility;
- much less friction.
It's a win-win.
It's not about fad. It's about being practical. You can fight for your freedom without rejecting everything closed source. We are all against slavery, but I don't see anybody on HN refusing to post a comment here because their laptop is being build by slavery labor in China. Which they all are.
Spend your energy wisely instead of living a dogma.
The GNU project would be promoting proprietary software by requiring free software developers to use proprietary software. As there exist free alternatives, such promotion would negatively impact the free software movement (people would say "why not use GitHub? GNU decided that it was okay!").
That is enough of a reason to discount proprietary services. It's that simple.
> much more visibility;
... for GitHub as well. Which is one of the main issues.
> We are all against slavery, but I don't see anybody on HN refusing to post a comment here because their laptop is being build by slavery[sic] labor in China. Which they all are.
Non-sequitur. "X is bad, so why are you caring about Y (which is less bad)".
As for non sequitur, it's not. There is no moral comparison, i'm just saying that practicality beats purity and that we all do it so advocating purity is defintly not credible.
This is like arguing that a member of the Vegeterian Foundation should buy chicken rather than chick-peas because chicken is easier to cook. Or because the chick-peas are being produced using animal fertilizers.
There are many criteria by which you can evaluate software. Usability is one of them. Software freedom is another. The GNU project proritises the latter over the former.
More importantly it's got nothing to do with "purity". I really don't understand how people are surprised that the Free Software Foundation prioritises Free Software as a criteria over anything else.
And GNOME is part of the GNU project...
> And of course Savannah would come first
There's no reason why GitLab could not also get an A rating, aside from friction from GitLab themselves.
https://gitlab.com/gitlab-org/gitlab-ce/issues/15678
More discussion can be found in the archives:
I never said it wasn't, I was just saying that the only meaningful blocker is on GitLab's side (though as you've mentioned in that thread there is some discussion on refining the requirements).
> There's discussion (stalled) here:
Emphasis on "stalled". ;)
I was just praising them, not disagreeing with you. :)
And still, it doesn't get to the heart of the issue, we're not comparing ethical viewpoints here, we're asserting product quality from a user standpoint.
I don't know what you think the GNU project stands for, but I find it incredibly hard to believe that they would not give GitLab an A rating if they followed the requirements (which are publicly listed). As an example, they promote GNU/Linux distributions that are not funded by the FSF[1]. Same goes for the FSF's "Respects Your Freedom" mark -- they reward it to anyone who passes the requirements.
The GNU project regularly promotes non-GNU projects. This is all just FUD.
> we're not comparing ethical viewpoints here, we're asserting product quality from a user standpoint
That's what _you're_ discussing. One of the factors in GNOME's decision is the ethical concerns of the GNU project (since they are a member of the GNU project and ethical concerns are the main crux of the GNU project).
Nonsense.
They have 2 reasons for it getting an F rating.
> 1. Important site functionality does not work without running nonfree JavaScript. (C0)
Contradicts what you say.
> 2. Specific information may not be available in all countries
Both are abiding by laws restricting access to that content. If you have an issue with that perhaps talk to the relevant governments.
> see roskomnadzor[1]
This was blocked by the Russian .gov, nothing to do with GitHub
> and export controls[2] for more details.
They are a US company hosted with a US provider complying with US laws on exporting controlled data.
So to counter your point one issue is because they're using non free software, one reason is out of their control, and the other is following the law of the land they are doing business in. If this is a fail in the FSF then that's fine, claiming they have "more severe problems than not running free software" is disingenuous.
1. https://github.com/github/roskomnadzor/blob/master/2014-10-2... 2. https://help.github.com/articles/github-and-export-controls/
> Contradicts what you say.
... no it doesn't. GitHub has server code and has JavaScript code that is sent to the client for the client to execute on the user's machine. This requirement is referring to the client code not the server code. The former is more of a matter of user freedom than the latter.
More importantly this requirement doesn't even require GitHub to make their JavaScript free, they just have to make their site work with JavaScript disabled.
I'm not sure how you could possibly read the requirement as saying "all server code that GitHub has must be free software"...
> Both are abiding by laws restricting access to that content. If you have an issue with that perhaps talk to the relevant governments.
GitLab doesn't get a ding for this requirement, so clearly this statement may be true but it doesn't seem like you are required to act the way GitHub does by law.
> So to counter your point one issue is because they're using non free software, one reason is out of their control
They have written proprietary software and sell it. I admit that it's hard to fix this problem if you already have proprietary code (contractors retain copyright in some cases), but pretending like they were completely at the mercy of someone else is ridiculous.
In the case of Roskomnadzor, GitHub is not under the jurisdiction of the Russian government---they made a choice to comply. They could have instead chosen to stand up to the Russian government, which would surely upset its citizens and the world and possibly lead to change. Possibly not. It's certainly a gamble.
rms drew a hard line on this. When I asked him about Roskomnadzor specifically, he was not moved. Quite the opposite, in fact.
I forget what he said about the export controls; I'll have to look at my mail archives tonight. But if they are complying with US law, and they have no choice, I don't think they'd be penalized in these criteria.
Not everyone has the same metric for success. Getting stars on a developer-only site doesn't seem to fit any of the gnome-desktop-project long term goals. Getting stars on a developer-only site seems at least a semi-useful goal for a programming language, at least in some sense.
Think about that statement. One of the most popular programming languages in the world "gained more visibility" because a few thousand people / bots clicked a button.
Did (useful) contributions increase?
Did more people start using python because they could fork the core of the language, and have a stale copy of master in their account?
[1]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5760
It's so good, I am both surprised and angry I didn't find it sooner.
Coming to Mercurial, now that I have been using it for more than a couple of years, my experience is that, this workflow (which is now considered standard and well known through git and github) isn't possible to achieve. Mercurial's concept of branching doesn't fit into this scheme of things. They stamp each commit with a branch id and there's no way to erase that which effectively leads to a lot of issues if github has to support the model that I mentioned above - a model which is well known and popular at github. Mercurial recommends bookmarks for cases like these, which based on my experience and some of the discussions in mercurial dev list, doesn't work either. I hear they are working on a "evolve" plugin in Mercurial to sort out some of these issues. But overall, it's still very complex and requires a deep understanding of the mercurial concepts/commands to achieve what can be achieved in git pretty easily.
Given all this, I personally don't think it adds much value for github to support mercurial in such a way that the workflows remain (almost) the same irrespective of what underlying version control system you use.
yes please
I actually spent most of last week working with Gnome edits.
One thing to note however. I use Fedora and the latest version moved away from X11 to using Wayland as a default (they can be switched).
Wayland is fine except its not viable for the gaming community. I am not a gamer, but I work with GPUs, so up until the past year with big moves from khronos to get GPU dev abstracted from just the gaming dev community, my dev dependencies are still tightly tied to the gaming community.
Theres also some things about Wayland that make it a bit premature in my opinion to be a Fedora default, though I appreciate Fedora being experimental in all of their releases.
To switch back to X11 from Wayland, which in my case was not for anything fancy GPU related, just to actually disable the touchscreen on my Asus UX303ub zenbook with a skylake processor. Wayland can't do that....
I had to downgrade gnome, and edit both wayland.conf and X11.conf files to switch X11 back as a default and then force disable the touchscreen.
This requires me to use an older version of gnome.
Why is this relevant? Because I'm not the only one right now retrograding gnome because of Wayland/X11 defaults. A huge majority of the PC gaming community operating outside of Windows OS is.
For me, in addition to doing all this, which only took a few hours to figure out, I had to reconfig releases of the gnome themes I use to get everything working. That being said, I'm obsessive about minimalist set ups and having a synchronized desktop/terminal tmux/vim setup for development, so I will spend 6 hours to get a tiny aspect working the way I want it to.
Right now, alot of experimental OSes using gnome are using different versions of gnome, so there might be overall less convergence on people using versus working on the latest gnome if it were moved to git.
That also being said, people who do that kind of thing are the people who will be deving on gnome, and it's what got me into UI linux dev in the first place.
That also being said, people in this world of gnome dev, are all using different versions of gnome.
That being said, it could help expediate convergence of gnome with upgrades to various Linux distros, as I know theres some mismatch between what I'm using with Fedora right now to have some basic default settings work.
However, I'm still in favour of moving it to git. I would love to have access to gnome dev that way.
I know I'm not the only one...
I think a lot of us here on HN are the same way. But if you want a minimalist desktop, why in the world run GNOME? In my experience, XFCE and LXDE are both at least as stable as GNOME and far more lightweight. Or you could go all in and run a tiling window manager like i3 or Awesome.
I havnt tried i3 or awesome.
I use VIM almost exclusively except in some more applied settings for maybe specifically an app.. and tmux works really nicely with Vim. That's why everyone says "tmux and vim should just get married and get it over with already" as a quote all over the internet. It could be the case with the other two as well.
tmux also has a really easy way to create your own plugins, and tmux persist sessions for savings windows and setups through reboots.
Again, these were things I wanted and found tmux to offer, while working really well with unique vim setups I had integrated across multiple computers. I don't know if i3 or awesome has these same features, but I think tmux is a good setup and I don't see a need to switch especially with tmux persist.
I'd be happy to hear recommendations about i3 or awesome over tmux advantages. tmux is so great to me, so if you had some good examples of how i3 or awesome trump tmux then I would definitely listen and consider and look into switching more. I've never had an issue with tmux and have really really liked it, and found every aspect I need to be easily customizable through .confs and never had to work with a predecided set of options rendered through a gui type customization, which I always find limiting for me, rather than just knowing or learning what to type in the .conf file for sys configs and having it just work.
DESKTOP THEMES I've only recently switched to gnome and used LXDE before and really liked it. I try to ride with Fedoras upgrades, and I know there were alot of opinions going around about having the default installs being switched to gnome, but I have not had any runtime issues with it.
That being said, I have a really powerful laptop, the one I'm running gnome on (other is a hackintosh but thats not by choice its for dev reasons), so I don't find anything I do on my laptop being compromised due to gnome, maybe my own bad code, but not gnome.
That being said, outside of initial testing of my skylake, I mostly run testing on centos on other systems and my main laptop currently running gnome, is an interface for which to run other setups I effectively use as servers or actual servers (and tmux persist sessions make it great to do that easily and save my entire detailed setup if i have to suddenly walk away from a detailed complex environment and not come back to it for two days and pick up where i left off, and that happens often considering I work simultaneously on multiple projects depending on my priorities for variable work schedules and more entrepreneurial endeavors.) so I don't find myself fighting over computing resources because of gnome.
I have not used gnome since I first tried ubuntu about 7 years ago, so I've had it for about 6 months before and not too many issues, only with integration for other unix setups, which is exactly why I think making dev on it more accessible or inviting to people (gitlab being a good venue for it aside, any venue) is a good option.
so far, I've been really happy with gnome since i came back to it. It took me about 3 hours to be set up and learning how to customize and make my own themes for it.
Gnome is not a bad desktop and it could benefit from more development by users who care about these things, minimalist setups and are constantly aware about runtimes and computational efficiency in every piece of code they write, which sadly...and somehow, many people missed day 1 of learning coding (big 0) and never seem to consider it until everything is breaking, and then say "hey lets throw this on AWS without exploiting the backend at all to optimize for the GPUs were paying for at the kernel level and assume AWS will figure out how to optimize our code at every layer instead"
at the low level, I've never done any custom mods on LXDE, so I can't sit here and pretend like I know some really good comparisons on computational efficiencies and design of LXDE versus gnome, but I think gnome is a fine interface, but could benefit alot still from more user dev.
Thanks for the reply and open to any other suggestions you have.
I still consider myself an amateur at everything computer/compsci related. I only minored in Compsci and code 30% of my time at work and then alot outside of work, but I'm not a top level dev by any means. I'm an Electrical Engineer (one of those I know) and code because I want to..not to mention due to the overlap.
So I'm always grateful to get feedback from people who spend more time exclusively working in this space than I do.
Even Linux used the closed bitkeeper for a long time
The fact that Linus used proprietary software to manage Linux was not seen positively by the community and eventually (after one of the developers tried to write a free client to interact with their proprietary service) everyone in the free software world got a reminder why we shouldn't promote or use proprietary services (the "gratis tier" access got revoked for the project).
Hosting on a git based system will lead to more people discovering and reading the code and ultimately contributing. This benefits everyone. Gnome has truly excellent projects and the more people work on them the better we have it.
However, this is one case where being a curmudgeon about being hosted on an open platform will shunt the possible growth of contributors.
Please use github instead.
[1]: https://www.gnu.org/software/repo-criteria-evaluation.en.htm...
And, in keeping with the FSFs view on software freedom, the server code actually doesn't need to be free (though it is considered a negative and will prevent a service from getting an A rating). However they _do_ require that the site must be possible to use without any non-free JavaScript.
Here is the full set of criteria that GitHub fails to fulfil to get a C rating:
> Things that prevent GitHub from moving up to the next grade, C: > * Important site functionality does not work without running nonfree JavaScript. (C0) > * Specific information may not be available in all countries; see roskomnadzor and export controls for more details. (C2)
That's it.
[1]: https://www.gnu.org/software/repo-criteria-evaluation.en.htm...
I mean as a developer your code repositories are the single most important thing where you want to sleep well (and your production infrastructure). Rather save money on shitty cinema tickets, Starbucks milkshakes (the shit they produce cannot be called coffee) or save some money on some shitty Apple adapters, but please get yourself a GitHub subscription.
That said, given the option I would rather use Phabricator (as I currently do).
I am sick of hearing this argument. What does that even mean? How is the fact that GitHub doesn't publish their internal code making it's usage "uncomfortable"? Do you think that if they opt to use GitLab and GitLab goes down (and they will because they are shit) that they will adopt GitLab's source code afterwards to continue the project because they rely on it? No way... they will just move their git stuff to a different provider, done. So what's the worry about a private hoster? Git itself is open source which is probably what matters more.
However, you're missing the point. Using proprietary software for hosting means that contributors are forced to use the same software (thus giving up their freedom). Not to mention it would promote proprietary software over free software. Neither is acceptable for the GNU project.
Why are people surprised that the GNU project prioritises freedom over all other factors? That was sort of the whole point of the project in the first place, and compromising on that would mean that modern GNU/Linux wouldn't exist.
The problem is that GitHub's client code is also proprietary (namely their site does not function when proprietary JavaScript is blocked), which makes it a user freedom issue.
However, their server code being non-free is additionally problematic because it would mean that GNU was recommending the usage of a proprietary service when there are free software alternatives. Which goes against the mission of GNU.
> If a software developer doesn't want to pay for GitHub, then what on earth deserves to be paid for.
When I use the word "free" I am referring to software freedom, not price. Please re-read my previous comment with that context in mind.
[1]: https://www.gnu.org/software/repo-criteria-evaluation.en.htm...
It is very hypocritical to promote free software while using proprietary software that you got special privilege for on the backend. KDE had the same line of thought when they chose Phabricator - if features like LDAP weren't locked behind Gitlab EE they would have used that, but they were only considering freedom respecting options, because they are communities of hackers that want access to improve their tools.
I wrote https://news.ycombinator.com/item?id=11092182 but I can't find LDAP references in any of the linked emails.
[1]: https://www.gnu.org/philosophy/who-does-that-server-really-s...