I hope Drew success with this! It sounds great in the most pure sense of the word. Totally open source, provides real mailing lists (being limited to issues is really limiting, it both hinders...
I hope Drew success with this! It sounds great in the most pure sense of the word. Totally open source, provides real mailing lists (being limited to issues is really limiting, it both hinders discussion about the project and waters down the utility of issues and issue comments themselves), has nice CI, no shady stuff (tracking etc.), and an actual business model. I just got an account there to test this out later. I was planning to slowly migrate from Github to Gitlab, but it seems like this changes my plans.
During the alpha, free accounts are not limited in any way. After the alpha, free accounts will not be allowed to own resources, including git repositories, bug trackers, mailing lists, etc, nor submit builds on builds.sr.ht. They will, however, be able to contribute to projects maintained by paying users.
It's a paid service -- accounts are just free until it's out of alpha/beta. All of the plans include all of the features (so it's kind of pay-what-you-want). The plans are: "Amatuer Hackers":...
It's a paid service -- accounts are just free until it's out of alpha/beta. All of the plans include all of the features (so it's kind of pay-what-you-want). The plans are:
"Amatuer Hackers": $2/month or $20/year
"Typical Hackers": $5/month or $50/year
"Professional Hackers": $10/month or $100/year
It also notes:
Just here to contribute bug reports, patches, and so on, to existing projects? You don't need to have a paid account for that.
It's actually pretty easy! First (optionally but recommended) go to the repository you want and set the default To: address. git config sendemail.to mailing-list@example.com Then when you want to...
It's actually pretty easy! First (optionally but recommended) go to the repository you want and set the default To: address.
git config sendemail.to mailing-list@example.com
Then when you want to send a patch, just use git send-email -1 to send the last commit, or -10 for the last 10, etc.
To each their own, but this will, unfortunately, be a deal breaker for many people. Managing pull requests is one of the key uses for the git service I use, and it would have to be there for me to...
To each their own, but this will, unfortunately, be a deal breaker for many people.
Managing pull requests is one of the key uses for the git service I use, and it would have to be there for me to really consider it. I'm going to try it for some personal projects, but not sure if I could convince my organization to make a switch.
Well... This means that every interaction would require a new page load every time. It just looks unefficient to me, but probably I'm understimating some of the benefits. It's just that I can't...
Well... This means that every interaction would require a new page load every time. It just looks unefficient to me, but probably I'm understimating some of the benefits. It's just that I can't really figure out one.
Are you referring to some specific features? Is there some kind of live interaction you feel is truly required for a modern website? I can't really spot anything missing by cursory look at the site.
Seems you'd have to rely on weird browser hacks for live interaction rather than using the standard scripting environment.
Are you referring to some specific features? Is there some kind of live interaction you feel is truly required for a modern website?
I can't really spot anything missing by cursory look at the site.
I don't have an account so I can't comment on this site specifically. However Github makes excellent use of AJAX to have content update live upon interaction. Merging PRs, commenting, applying...
I don't have an account so I can't comment on this site specifically. However Github makes excellent use of AJAX to have content update live upon interaction. Merging PRs, commenting, applying labels, and posting reactions take place without requiring a browser refresh.
Possibly the notifications work on AJAX as well, but I don't know for sure.
The alternative then is - like sr.hat has chosen - to make the refresh as quick as possible. Personally I think the middle ground Tildes has made is much more practical, but there certainly is...
without requiring a browser refresh.
The alternative then is - like sr.hat has chosen - to make the refresh as quick as possible.
Personally I think the middle ground Tildes has made is much more practical, but there certainly is value in optimizing for no scripting at all.
If you're very careful to design your pages to avoid state changes (eg. pressing a button with a half-typed comment), then this sort of design is possible. It's just very limiting.
If you're very careful to design your pages to avoid state changes (eg. pressing a button with a half-typed comment), then this sort of design is possible. It's just very limiting.
I hope Drew success with this! It sounds great in the most pure sense of the word. Totally open source, provides real mailing lists (being limited to issues is really limiting, it both hinders discussion about the project and waters down the utility of issues and issue comments themselves), has nice CI, no shady stuff (tracking etc.), and an actual business model. I just got an account there to test this out later. I was planning to slowly migrate from Github to Gitlab, but it seems like this changes my plans.
What is the bussines model? Could not find anything about how they finance themselfs. And accounts seem to be free.
The billing FAQ states:
It's a paid service -- accounts are just free until it's out of alpha/beta. All of the plans include all of the features (so it's kind of pay-what-you-want). The plans are:
It also notes:
https://man.sr.ht/billing-faq.md
I signed up, and will be testing it out. Not having pull requests is going to be a big change, never emailed patches around.
It's actually pretty easy! First (optionally but recommended) go to the repository you want and set the default To: address.
Then when you want to send a patch, just use
git send-email -1to send the last commit, or-10for the last 10, etc.edit: typo
To each their own, but this will, unfortunately, be a deal breaker for many people.
Managing pull requests is one of the key uses for the git service I use, and it would have to be there for me to really consider it. I'm going to try it for some personal projects, but not sure if I could convince my organization to make a switch.
Ok, this will be the dumbest of all questions, but I really cannot find an answer by myself: no javascript? Really? How did you manage that?
Is there anything in particular that you can't imagine being done without JS?
Well... This means that every interaction would require a new page load every time. It just looks unefficient to me, but probably I'm understimating some of the benefits. It's just that I can't really figure out one.
To me, no JavaScript is one of the best selling point of the service.
Seems you'd have to rely on weird browser hacks for live interaction rather than using the standard scripting environment.
Are you referring to some specific features? Is there some kind of live interaction you feel is truly required for a modern website?
I can't really spot anything missing by cursory look at the site.
I don't have an account so I can't comment on this site specifically. However Github makes excellent use of AJAX to have content update live upon interaction. Merging PRs, commenting, applying labels, and posting reactions take place without requiring a browser refresh.
Possibly the notifications work on AJAX as well, but I don't know for sure.
The alternative then is - like sr.hat has chosen - to make the refresh as quick as possible.
Personally I think the middle ground Tildes has made is much more practical, but there certainly is value in optimizing for no scripting at all.
If you're very careful to design your pages to avoid state changes (eg. pressing a button with a half-typed comment), then this sort of design is possible. It's just very limiting.