Roku developer repositories moved from GitHub to GitLab

Isn't being able to self host it on your company network a big important feature? Like for all the non-public branches and projects you keep internal. Gives you the same UX for everything.

This sounds pretty annoying though: https://docs.gitlab.com/administration/license_usage/

Gitlab is terrible at cross-group permissions if you use dedicated or self-hosted. Because gitlab.com is made to keep top level groups separate (separate tenants). Things like cross-group MR approval, use of the built-in artifact repositories, terraform module registry, gitlab components, and so on...is very messy...so many granular cross-group allows you have to turn on.

Gitea is shady af. Use its fork Forgejo instead. That's where all the original developers went.

From my experience nobody uses them, they just want a pretty ui to view job status and logs.

> Maybe Bending Spoons will make a move if the stock revisits its lows.

Which would be sad, because then quite a nice project is going to die.

The core open source version is called Community Edition like IntelliJ. That tells you something when most projects use the unqualified name and then have Enterprise or Cloud as paid services.

They take contributions but not if they would add the equivalent of a paid feature to the free version, they see it as reducing the value of enterprise in any way or just going against their vision. It's clearly a company run project, not even a hybrid like Redis or VSCode.

i don’t think they would accept a pr given that someone from gitlab closed these issues on purpose and provided a reason. a few of them might have even been PRs, i forget

What predicament are we in?

I hope for more indie, in games and software - more lifestyle & small businesses - where creativity and uniqueness can flourish

I still can't believe EA just shut down Bioware.

Of course considering who just bought EA (PIF, a Saudi fund + Kushner and some other asshats) and it all makes sense. But I'm still shocked and really sad.

"independent" may be a misnomer these days, much of it is catering to the audience and political alignment, with people living in different realities

the new incentives do not seem to have served us well, and perhaps worth noting that the same oligarchy controls the algorithms of the new platforms

I've heard this is a recent clout chaser trend, more with smart TVs directly than a stand along accessory.

Not sure if that translates into real demand for it, most consumers are going to consumer.

They are also a media company. They run the Roku Channel streaming service which produces original content and also has a 5% share of all us tv viewing tv viewing.

Paramount+ has a 2.5% share and Disney has a 4.7% share for comparison.

https://advertising.roku.com/learn/resources/nielsen-gauge-4...

They are an ad and media distribution company.

The hardware looses them $80m+ while the add and media distribution brings them in $1b+.

The hardware is a side hustle run at a loss to acquire users for the main business.

Microsoft hasn’t owned any part of MSNBC since 2014.

The reason MSNBC recently changed to MS NOW is because the relationship to NBC ended.

We're going to need something more expansive than OSI software licenses for the future.

Something like, "if you look at us, we must be able to look at you"

If the repos are public, hosting location doesn't make a difference.

Weird. I’ve been on a self hosted enterprise gitlab and I think we’ve have only one or two performance degradations/outages in the past 6 years

I was responsible for administering a self hosted GitLab instance for a medium sized company and our backups never required downtime. The built in backup command doesn't require downtime but also isn't a consistent point in time snapshot (specifically because the instance keeps running while the backup is being taken). If they've decided they need one for some reason, stopping GitLab is certainly the easiest way, but not the only way of accomplishing that goal, but that'll be true of any self-hosted forge, including GitHub.

This only happens on poorly thought pipelines and GitHub actions model or Jenkins high level directives won't make up for it. Eventually it'll break.

In Gitlab you can use the main file for describing high level stage pathways (tests, builds, deployments...) and offload individual control of jobs to granular files. Tests can be self contained child pipelines. Templates make them easy to replicate and components give them more flexibility.

You can do a lot more than GitHub actions with a lot less complexity than Jenkins.

What makes it more complicated than doing a Git push against two remotes? Assuming that one of those is used for collaboration and the other is just a mirror.

The breadcrumbs start here: https://github.com/hofstadter-io/hof/tree/_next/lib/agent (my personal developer swiss army knife)

I'm gearing up for a major rewrite, there is a lot of cruft in there from nearly 10 years of my experiments and explorations :]

Then my comment could be repeated verbatim, no?

What’s so much better about it? I use both and I don’t see significant differences, but I’m happy to be enlightened.

I don't understand why GitLab CI is praised so much when it is the most limited and unintuitive ones of all the CI systems I've worked with.

I have hit so many issues and limitations on GitLab which is just simply possible on GitHub. Here's a few of my rants with GitLab

1. The smallest unit of action on GitLab is a whole job, on GitHub, that's a task. So all of the actions or templated files can perform a single task instead of a whole job. This granularity is incredibly useful and lets my team create a catalog of actions that our downstream teams can simply include and compose it over a variety of tools and frameworks.

2. You cannot share secrets between jobs. This was just outright ridiculous when it meant that in each new job you have to fetch an STS token even though the token from a previous job would suffice. So much repetition. When you have a template like fetching AWS credentials using OIDC, that's the only thing you can do. Hence proving point 1.

3. Multiple workflow files instead of a single `.gitlab.yml` with a scrambled mess of rules

4. Dynamic services, in GitHub it is effortless to build a matrix AND have services spun up from it. The amount of duplication this reduces is insane.

    name: Test Actions

    on:
      push:
        branches:
        - main

    jobs:
        preTest: 
            runs-on: ubuntu-latest
            outputs:
              services: ${{ steps.services.outputs.serviceJson }}
            steps:
              - uses: actions/checkout@v3
              - run: echo "serviceJson=$(cat .github/workflows/demo.json | jq -c)" >> "$GITHUB_OUTPUT"
                id: services
                shell: bash
              
                
        test: 
            runs-on: ubuntu-latest
            needs: [preTest]
            services: ${{ fromJson(needs.preTest.outputs.services ) }}
            steps:
            - run: echo "Hello"
              shell: bash

> Can't mark PRs as drafts by default in GH

You can choose to create draft prs on the pr creation page and it will default to draft from there on. But this is per user and maybe per repo too. Besides if you’re using llms, you can set it to create draft prs.

I think this might just be a you problem.

> create new account

I don't think "need to create an account to figure out that you can't contribute with a given forge" is a real problem. They're just as publicly browsable sans-login as GitHub, for the same reasons: people want to share their stuff. And when you do need to make an account, most software forges have SSO with the big/common providers.

> find it archived, google for new repo, find that one archived, go to new repo

You needed to RTFM and do a bit of research to figure out where/how to contribute for GitHub projects too. They got archived/moved around/invisibly-forked just as often as people move forges today. How many times have you seen. "FizzBuzz is archived and no longer accepting contributions; an actively maintained rebuild of this project is at https://github.com/somebody/FizzBuzz-ng"?

> find they now take patches via email instead of PRs

Plenty of GitHub repos either don't accept contributions via GitHub PR (Linux) or require lots of nonstandard hoop-jumping to get a contribution approved (Python).

> 2-3 different protocols

Git is the protocol. I don't think the move away from GitHub is making anyone move away from Git. hg/jj/svn are still minority tools for the same reasons they always were.

> one index

It's Git. The index is folders on your hard drive. List their origins if you forget the URLs of their forges. Make a browser bookmark if you don't want to keep the checkout around.

Under the most charitable interpretation of your complaints that I can come up with, contributing in a not-universally-GitHub world is like ... 1% harder per repo contributed to. At most. To the tune of, at the very absolute worst, like 2 minutes of extra work when making your very first contribution to a project. I don't think it's that hard to stop googling "ProjectName github" and start googling "ProjectName git source" or "ProjectName contribute code".

At its core, Meta uses a modified version of mercurial. Most of the cool stuff I was referring to is not related to the core "hg" operations but related to the server-side hosting (monanoke) and the platform for operations like code review (diffusion), CI/CD (sandcastle), and all kinds of other tooling (notable mention: interactive smartlog for its fantastic GUI). I see no functional reason why a company like GitHub could not make the "Hub" part of GitHub better. It seems like they basically just haven't because they don't want to.

> Not the op, and while your criticism of their negativity may be somewhat justified, the ask is kind of silly.

Not really. It's pointless to go around accusing everyone of picking what they believe to be subpar alternatives when they even fail to establish what the par actually is, let alone what would be a preferred option.

It's as if they post this blend of comments just to try to feel smug.

> There are a bunch of well known alternatives:

See, that's what makes these exercises pointless. Those might work for your weekend pet projects, where you have the luxury of wasting all Sundays toying with how to deploy CICD systems because you have nothing better to do. For actual work, not so much. For example, SourceHut is renowned for being in perpetual alpha. It's baffling how it's being floated as a reasonable alternative to either GitLab or GitHub. Here's what they have to say about the risk of choosing them at this stage:

https://sourcehut.org/alpha-details/

Yes, though enterprise is expensive and GitLab still had a free option last time I checked.

It's a paid enterprise offering vs GitLab Open Source

SourceGit is fantastic:

https://github.com/sourcegit-scm/sourcegit

Both GitLab and Bitbucket still offer free repos for hobbyists.

What I'm thinking of is a company that exclusively caters to the enterprise.

You get a support engineer and they help on everything, migration, CI/CD, hosting, etc.

Nothing goes down without a solid 3 page write up.

It’s a dream, I don’t have the money to do it.

But it could work as a franchise model too, maybe I just refer your company to an affiliate located in your country of choice.

For example, most European clients would pick German locations.

If I was in the EU I’d be applying for a grant to build on the idea. Their’s no rational reason for European companies to fully trust Microsoft to act in good faith.

Thank you for the blunt feedback.

Ideally this would be DevOps as a service. But I’d have to charge an absurd amount of money to do it right.

Back to the drawing board

I mean, last year, but if you're updating once a week now, that means you've had 6 days to get exploited.

Hardly any different from dealing with Amazon or Google clouds problems and support, other FOSS darlings.