Hopefully this will be ForgeFed [0] standards support, allowing forges such as github, github, gitea, sourcehut, notabug, etc. to interoperate via ActivityPub-based federation.
ForgeFed opens walled gardens and allows anyone to interact with any repo with a single account regardless on where it resides. It is still in early development stage, but received funding from NLNet which will be distributed among contributors working on roadmap items [1]. Additionally feedback is requested via the Feneas forum [2] so make yourself heard :)
[0] https://forgefed.peers.community/
But is GitHub big enough they can just ignore it and go "bah we're too big now to care about others"?
While GitHub remains the "home" of open source (at least for cool, hip JavaScript projects).
Based on Hacker News threads, SourceHut is challenging GitHub in "coolness" too. ️
Whilst GH has duplicated these features very recently, they are still things that are at the core of gitlabs offering, so are generally higher quality and better supported.
Gitlab is also open source, which lets me mirror their repo locally in case they die or remove a feature I use.
Oh, and gitlab isn't systematically racist, which is always a personal ethical win.
Shout out to sourcehut as a possible next cool thing - currently in public alpha
Wait, what? How is GitHub "systematically racist"?
> Shout out to sourcehut as a possible next cool thing - currently in public alpha
Sourcehut seems like a niche product for a niche audience. That's not a criticism – if anything, that's a compliment because too often people with niche needs or preferences are left out in the cold, but I don't think it'll be anywhere near the "next GitHub".
https://todogroup.org/members/
Discussion of the code-of-conduct:
* https://github.com/dear-github/dear-github/issues/107#issuec...
on:
push:
branches:
- "**"https://github.blog/2019-08-08-github-actions-now-supports-c...
The alpha was rougher (and completely different) but that's why it was called an alpha!
When I worked with gitlab CI, I've read through the documentation, understood immediately how it works, and had a pipeline up and running half an hour later.
When github actions was started, I approached it with the same mindset as I approached (for instance) travis.ci, AppVeyor or gitlab CI. But after reading through the github action documentation I had no idea how to make this work for a CI/CD workflow, so I ignored it and continued using travis.ci and AppVeyor for my github projects. Only roughly a year later the above mentioned CI/CD support was added to github actions, which finally made it useable in the same way as all the other CI services.
So my suspicion is: github actions was going to be a new "revolutionary" thing with a much wider scope than existing CI/CD solution. But most people didn't understand such a "visionary" concept, and instead just wanted a simple CI/CD service similar to all the 3rd party solutions that already existed, only better integrated with the rest of github.
And that's why I think that gitlab's integrated CI/CD service makes a lot more sense. It was much more focused on the developer's needs from the beginning.
I'm not sure what you think was "bolted on" to actions, could you be specific? Features have been added (during the beta and since) but I can't think of anything that could really be described as "bolted on". "bolted on" to me implies some kind of disharmony with other features, weird quirks etc.
> I seriously didn't understand what problems github actions were intended to solve
You can run arbitrary code in response to any GitHub repository event, and also cron jobs and external triggers (a GitHub app can POST to a specific API to trigger those style of workflows).
The code runs with access to GitHub APIs for your repo (it can clone it, leave comments, create new PRs, whatever), and in any event that is associated with a PR a check status gets added to the PR.
This is a pretty general-purpose tool and I think it's easy to imagine the kind of problems people would use it to solve...
> my suspicion is [...]
Honestly it sounds like you're not really familiar with it and have some strongly negative opinions. I'd recommend either giving it another look and putting aside your feelings or working on a more substantive critique...
I mean, I get the "new" Microsoft. And I get that this is mostly a street-cred move by them, and they'll try to not mess it up by interfering with it. But still. That's now. What happens when the next shake-up comes and there's a push by the accountants to make money off everything, that's the important bit.
It's like Atlassian taking over Trello. They'll mess it up, it's just a matter of when not if.
Before that they were their own company. And as far as I know, the source was never OSS to begin with. Microsoft didn't swoop in and lock it down. It was already like that.
In case anybody wondered if Github was closed-source because of Microsoft.
I am yet to find something that works as good as Atlassian products.
Individually they all have a lot of flaws to the point that if they only existed on their own, no one would use them. But features like native support for referencing Jira issues in Confluence and having them auto-update makes companies want to use it.
Part of it, I think, is the development tool version of "nobody ever got fired for buying IBM". It's considered the safe choice. Enterprise-y companies get wooed by all the "Atlassian consultants" floating around out there. The ecosystem is just designed to attract enterprise users.
Fair enough, I agree - they are not that poorly integrated as they are just really poor tools.
Their tools are remarkably slow, with each page both being remarkably JavaScript-heavy and constantly reloading (the two should be mutually exclusive, right?).
They really aren't bad, and have some advantages, but they are not a joy to use.
I'm not the biggest Atlassian fan, but they posted in August last year, gave 10 months notice and cited that less than 1% of new repos being created are using mercurial as their primary reason for doing so. If you cared about a project, almost a year is plenty of time to move it. I don't think it's entirely unreasonable to sunset a feature that is not widely used by your users, not widely used outside of your userbase, and that requires ongoing maintenance that the other 99% of repositories could benefit from instead.
That's not OK and I'm clearly very, very angry as a former user.
I mean, it's still there. If it's that much of an issue, and the tooling has been made by the community, you're free to archive it now. At what point is it ok for them to say "hey, we don't want to pay to store the data/keep the codepaths to display/interact with this data" anymore?
How many of those people were paying customers before this? I don't know the answer offhand, but if I had to guess, I'd suspect a small number of them.
> That's not OK and I'm clearly very, very angry as a former user.
I hope as a paying customer, you cancelled your subscription to them and told them explicitly why then.
At the point when they make it super easy for the people to archive the data themselves. Code part is easy, PRs, issues and downloads are hard. See: Google takeout
> I hope as a paying customer, you cancelled your subscription to them and told them explicitly why then.
Not just even for me, I made my company switch to it, and we were also hoping support for mercurial in the future, but were okay with it not supporting mercurial in local deployments, we had our hg repos on bitbucket.org. When the news broke, I moved to GitHub and perkeep (for archiving all the JSON data that I painstakingly had to scrape), and my (now former) company found a smaller vendor that offered what BitBucket was supposed to offer but never delivered, only for 100x the price (although one-time, custom development for them).
Yes exactly that, i think for bit-bucket it would have been less damaging NOT to support git but exclusively mercurial..and maybe bitkeeper ;)
It can be whatever people want to use it for. The customisation and the key features of the tool are not bad. Then again, most tools are neutral until a person wields them.
[Edit typo]
I have endured all, from web forms storing their data via Perl CGI scripts to Excel sheets which require a PhD in VBA macros to change anything.
Still a great fan of Trac. Old but gold, simple and fast. Suffers a bit from a historical focus on SVN, but can be adapted to git easily.
I get that Jira can be poorly configured, but it's not Lotus Notes bad.
I've transitioned with companies from Github to Gitlab, from Bitbucket to GitHub etc. but never to Bitbucket. In fairness I was using Gitlab during their great outage, so I can say that cool is not always reliable. And coolness fades and dies relatively fast.
But I can't remember Bitbucket ever being cool.
And the ability to create a repo on their site by just pushing to a remote with the right name[1] has really made it easier for me to use their service. What do you find confusing and poor about the UI? I find it straightforward and efficient.
I do use the find-file feature on Github a lot, as well as the quick file editor. Both are missing here, but I kind of see that at least the file editor is not well suited to the projects ethos.
Using git and mercurial for large binary file storage is, 100%, wrong. Why? They're not designed for it, so they handle it really poorly. Hacks like Git LFS and annex were made for a reason.
From sourcehuts perspective, they need to serve all their customers, and an extreme performance outlier for a still small platform could degrade the experience for others by becoming a significant part of the server load. Thus, it's fair to say no.
Just like Github did back in the day to CocoaPod: https://news.ycombinator.com/item?id=11245652. They also got very unhappy.
Both the original story as well as the comments regarding Andrew's usage for Zig.
It's fine to not support certain use cases because it's too much effort or otherwise too expensive. It's not fine to, as a service provider, tell people that their programs are (and I quote) "wrong".
If you're okay with that then that's your choice, but for me it really turned me off sourcehut.
No, not really, if done politely. Which seems to be the case here.
It also might "work" to use a large crystal vase as a hammer, but it's still "doing it wrong".
If anything, I'd fault sr.ht for having too vague usage policies and then telling users they are in violation of said policies. That's not good. But they are in alpha, so hopefully it's something that'll improve.
Similar thing happened on Github with CocoaPods: https://news.ycombinator.com/item?id=11245652.
Just because something works doesn't mean it is a suitable implementation or a sensible decision.
It's a paid subscription website and has done very well as a one-man-army project. Its success hasn't compromised its virtues of being lightweight and no-nonsense (unlike Delicious).
If SourceHut could do the same for Git that would be great.
It already does. Other than some (minor) missing features that are in active development, what else do you need?
I made a typo (`git show` not `show show`) and the last one is from https://git-man-page-generator.lokaltog.net/
I use GitHub to get work done, either on my projects or on others. I do not expect GitHub to innately provide me a degree of fun. That's the job of the projects, not of GitHub itself.
Zoom exited the early adopter phase this past pandemic. It promptly was given significant attention, reasons were found to declare it "uncool", and Jitsi was elevated as the next "cool" replacement.
This article confirms that GitHub is now exiting the early adopter phase. Significant attention is being paid to it, reasons are being found to declare it "uncool" — but, no replacement has yet been elevated as the next "cool" replacement for it.
What will GitHub's replacement "cool" service be?