[HN Gopher] I no longer maintain my Emacs projects on Sourcehut
___________________________________________________________________
I no longer maintain my Emacs projects on Sourcehut
Author : goranmoomin
Score : 149 points
Date : 2024-03-12 12:00 UTC (11 hours ago)
(HTM) web link (protesilaos.com)
(TXT) w3m dump (protesilaos.com)
| NeutralForest wrote:
| Completely understandable and yet another example that
| practicality beats purity.
| pelagicAustral wrote:
| At least for me, the article keeps going offline intermittently.
| Archive link:
| https://web.archive.org/web/20240308111845/https://protesila...
| tetris11 wrote:
| Prot's thoughts echo some of the fears I had during the "slow
| leap" of 2018. I never made the jump to sourcehut, but I did leap
| to Gitlab, and have a general feeling that whatever small
| following I was building got snapped in half and never recovered.
|
| I just suddenly stopped engaging with the users in my projects.
| Also a good thing in some cases, but it made my work take on a
| new private and hidden aspect, which is the opposite of what I
| wanted (open collab, easy dialogue, connecting with like-minded
| peers).
|
| Gitlab just doesn't have the audience that Github does, and so my
| new strategy since a few months has been to develop on Gitlab,
| but to clone everything onto Github, just to get some audience.
| internetter wrote:
| I sheepishly collect analytics, and sourcehut provides similar
| relative traffic to my website as github does (I host more
| projects on github). Unfortunately nothing is immensely popular
| so I cannot say with certainty this will hold true, but I've
| observed high engagement with popular sourcehut projects.
| overstay8930 wrote:
| GitLab's UI really feels like it steers you towards work inside
| of a company more than open collaboration like GitHub does.
| Very segmented UI without discoverability.
|
| I prefer GitLab but I understand why GitHub is the default.
| Just different products and use cases.
| mikepurvis wrote:
| GitLab has some long open tickets about federating instances
| but the technical implementation of such a thing is really
| only a small piece of the puzzle.
|
| EDIT-- here's a newer epic trying to gather some of that
| together into a cohesive effort:
| https://gitlab.com/groups/gitlab-org/-/epics/11247
| mroche wrote:
| > GitLab's UI really feels like it steers you towards work
| inside of a company more than open collaboration like GitHub
| does.
|
| That's kind of what it was designed for, though. GitLab.com
| wasn't a popular choice for open projects compared to GitHub
| until the "big migration" several years ago. Before that,
| GitLab was _very_ popular for self-hosted internal instances
| (their customer reel demonstrated that). Even before
| modifying their OSS org policy for self-hosting, many groups
| ran their own GitLab CE instance. You couldn 't (and still
| can't) do this with GitHub*. It also had a longstanding
| unlimited private repos compared to GitHub's free tier
| (formerly) that enticed developers.
|
| GitLab's UI/UX was made for business workflows and processes
| (hence it being an "all-in-one DevOps platform." GitHub leans
| more into the community graph and semi-social media style for
| orgs/communities (the Discussions section a case example). It
| has come a long way for the business side, though.
|
| * Yes, GitHub Enterprise Server exists: good luck getting it
| without paying for it (unless things have changed).
| bigpeopleareold wrote:
| Did you find out why engagement stopped? Is a preference to the
| GitHub UI? Or, they simply don't want another site to deal
| with?
|
| If anything, the only value of GitHub to me personally is this
| vague rationale that 'people like that more' ... but I host
| everything on GitLab. But, what I host are really not active
| projects. That's the big difference possibly.
| zarathustreal wrote:
| I can't speak for most, but for me it's simply that GitHub
| operates more like a social media network for developers than
| a web-based git. As such I evaluate it by number of users
| because it equates directly to the number of social
| interactions I'm likely to have.
|
| Morally I would love to stop using Microsoft products, much
| in the same way I'd like to stop using Meta products, but the
| problem is that I'm not there for the product, I'm there for
| the people. I can find products that better align with my
| values but I can't bring along all the connections and
| possibility of connections
| raziel2p wrote:
| how do people use GitHub as a social media network exactly?
| I know the features are there but I've never talked to
| anyone who uses it.
|
| a simpler explanation is that GitHub has a simpler/better
| interface than alternatives, and most people already have
| an account.
| lutoma wrote:
| For me, it's two things:
|
| * Whenever I come across an interesting project hosted on
| Github (On Hacker News, Mastodon or some such place), I
| usually star it. Then when I'm later looking for a
| library or piece of software I usually search my Github
| stars first for a nice pre-filtered list of options.
|
| I know I could also use a bookmark manager to keep track
| of interesting non-Github projects, but that's way too
| high-friction and so in practice I usually forget about
| them.
|
| * There's also the social feed on the homepage where you
| can see which repositories your friends have
| starred/contributed to. I don't personally use this super
| often but frequently I star some repository and then
| notice a bunch of my friends starred it shortly after,
| presumably because they saw it in their feed.
| bigpeopleareold wrote:
| For me at least, I presume that the social network comes
| from the people you talk to, with whatever medium you use,
| when one is involved in a project, wherever the code is
| hosted. I never saw GitHub to be special. I got work from
| meetups, from participating on mailing lists, etc. but not
| GitHub. There is no tight link to it, but I can presume for
| myself that can be that case for a particular project. But
| - to each their own on this matter.
| brycewray wrote:
| > I can't speak for most, but for me it's simply that
| GitHub operates more like a social media network for
| developers than a web-based git. As such I evaluate it by
| number of users because it equates directly to the number
| of social interactions I'm likely to have.
|
| My final employer blocked GitHub as "social media" and
| rejected all arguments regarding its many other attributes.
| New CIO came in, heard of this, agreed it was silly and
| promised to have the block removed. Apparently somebody
| dissuaded him, because it never happened. Strange stuff.
| tetris11 wrote:
| > Or they simply don't want another site to deal with?
|
| This, mostly. Some of the contributors make mostly small (but
| important) documentation changes, and for them "Git" _is_
| "Github" since the UI makes all of it seemless.
|
| Asking them to create an account on another service to do the
| same will leave these new contributors scratching heads
| imiric wrote:
| > Asking them to create an account on another service to do
| the same will leave these new contributors scratching heads
|
| Honestly, this can sometimes be a good thing.
|
| Creating a bit of friction for contributors can separate
| the signal from the noise, leading to more meaningful
| contributions. We're all familiar with the fiasco and
| annoyance of #hacktoberfest on GH, and the incessant spam
| in popular projects and issue trackers.
|
| That said, the friction of Sourcehut might be too much even
| for people with good intentions, since it insists on a very
| opinionated workflow that's alien to most. The choice of
| hosting ultimately depends on each project's needs, as
| mentioned elsewhere.
| oefrha wrote:
| Two years ago gitlab.com stopped allowing anonymous users to
| search issue trackers[1], which is nuts if you want to host
| anything there for which your users might want to search
| through existing issues. I don't think I've interacted with
| gitlab.com again after that. It seems that stupid decision
| has been overturned now? Anyway they've lost me for the
| foreseeable future.
|
| [1] https://news.ycombinator.com/item?id=32252501
| couchand wrote:
| To some extent there's a horses for courses argument here: which
| projects stand to benefit from a high proportion of drive-by
| contributions? Which projects can appropriately leverage nuanced
| textual discussion?
|
| If the Linux kernel had been hosted on GitHub from the start it
| would have turned out very different.
| oldandboring wrote:
| > If the Linux kernel had been hosted on GitHub from the start
| it would have turned out very different.
|
| Of course I get the point you're making and agree, but this is
| still an amusing statement to read :)
| noobermin wrote:
| Should I put up the sircmpwn signal? Would be nice to see his
| take.
| lupusreal wrote:
| I thought he was banned for having unpopular opinions. Or was
| that just on lobsters?
| DaSHacka wrote:
| On lobsters he was banned for shilling sourcehut, and knowing
| Drew, I find it hard to believe he's not already in this
| thread one way or another.
| lupusreal wrote:
| That's farcical. He was banned for having strong opinions
| about many things, meaning that nearly everybody would
| disagree with him about at least something, if not
| everything. The result was that nobody liked him so a
| pretext for banning him was devised. Hell, I disagree with
| him on many if not most things, but I don't think he should
| be banned for it.
|
| Drew, if you're in this thread: I've argued with you
| several times before but the way you get 'canceled' for
| having strong convictions is an injustice. Stay true to
| you.
| xinayder wrote:
| > The SourceHut web interface does not show any kind of
| indication that a message has an attachment. Last time I tried
| it, I had to download an mbox file and extract the patch from
| there. This was helped by the fact that I knew what I was
| searching for, but the experience was not pleasant anyway.
|
| If it doesn't work as they expect, why not submit a PR to fix the
| issue on srht?
|
| I'm pretty sure all of the 4 points the author listed can be
| easily fixed either by code or by talking to some veteran
| sourcehut users and finding the best solution for the issues. The
| blog post make it seem like the author is just expecting srht to
| be exactly like GitHub, which it isn't, plus it does seem like
| they're lazy to try to fix this issues and have decided to jump
| ship instead.
| Timshel wrote:
| Or maybe he is busy maintaining his own projects and does not
| have time/ don't want to onboard and contribute to SourceHut
| ...
| lopkeny12ko wrote:
| Then he does not have a right to complain about SourceHut.
| gray_-_wolf wrote:
| Right, how dare he, complaining about a paid service.
| infecto wrote:
| Because something is opensource and "easy to fix" are we
| expected to not talk about it?
| xinayder wrote:
| No, it's just that srht was built with this in mind. If I
| were the author I would talk to some srht maintainers or
| people that have projects in srht to brainstorm solutions for
| my issues instead of just writing a blog post and jumping
| ship. The author doesn't mention at any time that they tried
| to talk to other maintainers about these problems.
| rootlocus wrote:
| > The blog post make it seem like the author is just expecting
| srht to be exactly like GitHub
|
| The author complains users don't use the mailing list correctly
| or at all. That's something the author expects to work the way
| srht intended, but the users expect it to work like github. And
| that's pretty much the point of the article.
| konart wrote:
| >If it doesn't work as they expect, why not submit a PR to fix
| the issue on srht?
|
| Because people have their own things to mind and does not
| always have time to commit to every oss project they use?
|
| Seriously, "just submit a PR" is the worst comment you always
| expect to see in a discussion.
| alberth wrote:
| My decision tree for selecting source control: Q:
| Do I want contributors? A: Yes, use GitHub.
| A: No, use whatever I want.
| abound wrote:
| This is pretty much where I'm at.
|
| If I want visibility and people to contribute, GitHub.
|
| If it's a truly private project (dotfiles dump, esoteric highly
| personalized tools), self-hosted Gitea.
|
| Everything else I put on Sourcehut.
| DonHopkins wrote:
| Q: Do I want to actively antagonize contributors while
| torturing myself? A: Yes, use SCCS.
| Havoc wrote:
| Definitely path of least resistance but also bound to get us a
| monoculture
| Tuna-Fish wrote:
| The monoculture already exists, and it was always going to be
| formed.
|
| The one good thing is that git makes it relatively easy to
| move, so that if Github suffers excessive enshittification,
| something else can steal their lunch.
| kibwen wrote:
| Git makes it relatively easy to move the code itself and
| its commit history, but not the other things people use
| Github for: issues, automation, CI... The lock-in is there.
| zelphirkalt wrote:
| Maybe this is making a good argument for managing these
| things as commits in a directory in the git tree?
| LightFog wrote:
| MSFT gobbling up your code and selling it back to you isn't
| enshittified enough for you?
| whatevaa wrote:
| Like public code on Sourcehut won't be gobbled up...
| LightFog wrote:
| And private code? MSFT make no promises private code on
| GitHub.com won't be trained on.
| mathstuf wrote:
| You can move the code, sure. It's the infrastructure that
| is hard to relocate (issues, pulls). If one uses references
| like `#123` in the history, you need to do something to
| keep them "alive" on a migration. GitLab itself has an
| interesting solution where instead of short references,
| full URLs are used so that they work in any context
| (including locally). These URLs are then rendered as `#123`
| or whatever depending on the location of the render.
| fsckboy wrote:
| > _git makes it relatively easy to move, so that if Github
| suffers excessive enshittification..._
|
| what if the enshittification is making it hard to move?
| mbreese wrote:
| The network effects associated with hosting code in a public
| source repository are just too great. If you want your code
| to be seen, used, trusted, you put it on one of the primary
| code repositories. At one point, this was sourceforge. For a
| while bitbucket had a good share. Then came GitHub.
|
| There are also always a few secondary repositories that share
| the same tooling, but still have less traction (like GitLab).
| But the network effects of GitHub are hard to ignore.
|
| But, like was said in a previous comment, it least it is easy
| to move Git repositories from one host to another. So when
| there is an inevitable successor to GitHub, we'll all be able
| to migrate to the next hotness easier.
|
| (That's assuming that the next hotness supports Git. Prior
| shifts followed from changing underlying technologies... CVS
| -> SVN or Hg -> Git)
| cybrox wrote:
| Even ignoring the userbase, GitLab or BitBucket would have a
| better chance at hosting thriving projects.
|
| Sourcehut has a very good and noble idea but it just adds so
| much complexity in the name of purity to a hurdle that is
| already very big for newcomers.
|
| They basically undo all the progress on collaboration since
| the 90s to get rid of the modern problems that these changes
| cause, without realizing that the way forward is to solve
| these problems, not just revert to a time when they didn't
| exist.
| Pet_Ant wrote:
| > They basically undo all the progress on collaboration
| since the 90s to get rid of the modern problems that these
| changes cause,
|
| https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's
| _...
| aidenn0 wrote:
| > They basically undo all the progress on collaboration
| since the 90s to get rid of the modern problems that these
| changes cause, without realizing that the way forward is to
| solve these problems, not just revert to a time when they
| didn't exist.
|
| Saying they are "reverting to a time when they didn't
| exist" is missing the point. It's about improving the
| problems that caused people to switch away from the
| collaboration tools in the 90s; e.g. [1]. So it's more of a
| fork of the 90s than a rollback.
|
| Also, it's not like the people at SH (and their users)
| haven't tried new collaboration tools. I (at least) have
| tried them and found them wanting in important ways. The
| conclusion that it's better to fix the older tools than the
| newer tools could be debated with[2], but nobody's sticking
| their heads in the sand here.
|
| 1: https://sourcehut.org/blog/2022-07-06-sourcehut-and-irc/
| Note also that even without SH, e-mail, IRC, &c. are all
| greatly improved in both small and large ways in the time
| between the 90s and now.
|
| 2: I mean everybody involved with SH already prefers the
| older tools for one reason or another, so fixing the older
| tools is going to be the obvious path forward for _them_.
| busterarm wrote:
| It's not about purity.
|
| It's about a workflow where everything lives in email
| rather than some company's walled garden.
|
| It also doesn't give a toss about newcomers. It's for users
| who want something very specific and know what that looks
| like already.
|
| It's like the same reasons that OpenBSD still uses CVS --
| it works perfectly fine for those involved in the project
| and the switch to Git would not only take time away from
| what's important to work on but also add a ton of noise
| from new contributors who may not have the same goals as
| the project.
| zilti wrote:
| What complexity? Sending an email using git instead of
| having to create an account and open a merge request using
| a web app?
| aidenn0 wrote:
| Just in case you are being serious, I would estimate more
| people have GitHub accounts than know how to submit a git
| patch via e-mail. Most people use Outlook, Gmail or
| Apple's Mail.app as their MUI and _I_ don 't know how to
| do it with any of those 3.
| Zambyte wrote:
| Why not just use both? The great thing about git is that you
| can easily coordinate multiple repositories (git push --all).
| The great thing about the web is you can hyperlink to different
| sites (link to related discussion on another forge). Source
| forges all send email notifications, so you can get updates in
| one place.
|
| The biggest problem I see is duplicate issues being raised
| across forge issue trackers, which using a single forge doesn't
| fix anyways.
| buovjaga wrote:
| A: Yes, provide mentoring and use whatever fits your needs.
|
| If you funnel potential contributors straight into mentoring,
| the popularity of the tools is not an issue.
|
| For visibility, there are many possibilities, such as volunteer
| platforms.
| zbentley wrote:
| Then those aren't contributors, at least not at first;
| they're mentees/students.
|
| Projects which can follow that practice are substantially
| fewer than projects who can quickly solicit contributions on
| e.g. GitHub: requiring mentoring restricts the field to
| projects whose authors have the time, skills, and inclination
| to mentor, and restricts potential contributors to people
| willing to be mentored in new tooling rather than the (much
| more common) case of people who simply want to provide an
| improvement to code with minimal friction (and often minimal
| other involvement with the project, if we're talking about
| point fixes for issues faced by the contributing user).
| sph wrote:
| The problem is wanting contributors. I want to release open
| source software, contributors (which mostly means bug reporters
| and entitled users) tend to be a drag turning a hobby project
| into work.
|
| Remember, open source doesn't mean to accept any inane
| suggestion or PR from anybody. The best software is the
| opinionated and limited-in-scope. If people want to add an MP3
| player to your project, they can always fork it.
|
| And since using GitHub basically means training AI undermining
| my career, for free, so that Microsoft can turn a profit, the
| choice is simple, really.
|
| Disclaimer: I am still using Github because I haven't found the
| time to set up my self-hosted Gitea instance just yet.
| Propelloni wrote:
| If you are only looking for a place to host your open source
| projects, you could take a look at codeberg.org.
| sph wrote:
| I also need to host private, commercial repos which are
| forbidden on Codeberg. When I migrate out of the Github
| loving embrace, I might as well self host and be safe
| forever.
| The_Colonel wrote:
| There's a sweet spot number of contributors which provide
| valuable feedback, testing, ideas and maybe some code. It's
| not that difficult to get to that sweet spot, the problem is
| staying there. It may happen that the number grows too much,
| and you get overwhelmed, burned out (eventually).
| sph wrote:
| That is true. In practice, a higher barrier of entry tends
| to result in higher contribution quality. You wouldn't get
| a lot of hackathon PR spam if one could only send a patch
| with git send-email.
| derekzhouzhen wrote:
| If I do not want contributor, then I'd just use plain git
| through SSH on my own VPS.
| chillfox wrote:
| lol, that's pretty much what I do as well. For me the
| "whatever" is usually a self-hosted fossil server.
| phpnode wrote:
| Github has network effects that will always be difficult for
| challengers to overcome. Even Gitlab is nowhere near taking over.
| GH is effectively a professional resume for many people, and if
| they're contributing to something they want that recorded on
| their profile. When was the last time a recruiter asked to see
| your Gitlab or Sourcehut profile? As far as they're concerned
| those contributions might as well not exist, and like it or not
| that really matters to people. In short, it's the people, not the
| code that counts.
| Cloudef wrote:
| In my experience github has no value in your cv/resume at all
| anacrolix wrote:
| I have to agree a stubborn portion of companies refuse to
| look at it. It's their loss. If a company does not respect
| open source contributions I think it's a good filter.
| tomxor wrote:
| I have so far found it to be a very good filter, helping
| eliminate BS or candidates grossly exaggerating their
| abilities. I've yet to experience the opposite but I have
| hope.
| phpnode wrote:
| I'm really surprised to hear that. My GH profile has got me
| plenty of jobs over the years and also allowed me to skip
| things like programming tests that are usually part of the
| interview process.
| bigpeopleareold wrote:
| Seems like you lucked out, because this never really
| happened for me. I wish this was the case! I have a ton of
| half-finished projects I could show instead of doing tests.
| foooorsyth wrote:
| Doesn't seem like luck if he actually finished his
| projects. Every undergrad has a github full of half
| finished projects. Seeing professional contributions to a
| widely used project is a completely different story.
| imiric wrote:
| Even half-finished projects can be a valuable reference
| if they showcase passion, good development practices, or
| some specialty skill. Contributions to popular projects
| are valuable as well, but they should also showcase some
| of these attributes.
|
| Something people often miss is that it's not enough to
| just link someone to your GH profile. If it's full of
| half-finished projects, they will likely look at your
| pinned ones (if you have those set), and not bother with
| the rest. The crucial thing is linking them directly to
| specific files of a project, specific PRs and
| contributions, that showcase the value you can bring.
| This makes the job much easier for the other side, while
| highlighting your strengths.
| gassiss wrote:
| half finished projects that you developed on your own don't
| hold that much value. They may pad those green stats, but
| those can be faked quite easily. It's contributions to
| projects with other contributors that really matter.
| nine_k wrote:
| Why work on half-finished personal projects when you can
| contribute to a high(ish)-profile public projects,
| especially such that your prospective employers might be
| using?
| voidnap wrote:
| I've seen jobs claiming they let you skip their tests but
| none have yet to do so. I have multiple conpleted side
| projects. They are small non-commercial but not trivial and
| solve a problem for me.
|
| You are fortunate, which is great for you, but your advice
| will not work for most people.
| jcelerier wrote:
| It certainly does for the people I've been hiring if they
| talk to me about open-source contributions during interviews
| theamk wrote:
| But would you accept their contributions if they were on
| gitlab, sourcehut, or some other server?
|
| Because GP implies only github matters and that does not
| seem like truth to me.
| bitsandboots wrote:
| As an interviewer it is the opposite to me. If there is a
| link showing your open source work, I want to review it to
| see if it indicates anything good or bad, and could be a
| topic for discussion. Too few people have good content there,
| so it can be a useful filter.
| kjs3 wrote:
| Me too. In particular, I look at how they handle pull
| requests. If it's full of derogatory comments or other
| asshole-isms, probably not going to be a fun person to have
| on the team. If they handle the occasional annoyance with a
| modicum of professionalism, it's usually a good sign.
| criley2 wrote:
| I tend to agree. My company (and many other companies) don't
| let you use a personal github account for company code, so we
| have separate accounts for the businesses private repo.
| Obviously these contributions can't appear on my personal
| github account.
|
| The other issue is that commit activity is just a very poor
| signal for engineer quality. I've met truly terrible
| engineers with the brightest green activity boards you'll
| ever see. And I've met absolutely brilliant wizards whose
| activity board is very sparse.
|
| Seniority is another issue -- as you grow in an org, you
| won't always grow in a way that leads to more contributions.
| I personally am spending a lot of time pairing, a lot of time
| leading, and a lot less time busting out individual tickets
| with constant commits.
|
| I've also found that instead of taking 30 commits over 2
| weeks to finish a project, the more experienced I get, I can
| do the same work in 5 commits over 3 days. It's just the
| nature of experience. But which one looks better on the
| github activity graph?
| marcosdumay wrote:
| You mean that if you sent links to your Gitlab or Sourcehut
| profiles (or even your personal site) when asked for your
| Github profile, those recruiters would refuse to look at it?
| phpnode wrote:
| yeah i think they're much less likely to look at it, unless
| they're already significantly interested in you as a
| candidate for some other reason. We're in a competitive
| marketplace and having a profile that stands out is
| definitely an edge
| account42 wrote:
| Wouldn't a personal site stand out more if everyone has a
| GitHub?
| phpnode wrote:
| remember that a recruiter is probably spending about 30
| seconds assessing your job application, and that you're
| one candidate out of dozens. In that environment they're
| going to go with the easy route and showing them a bunch
| of pinned, interesting repos with a healthy number of
| stars in a format they're used to is going to help them
| to quickly put you in the "maybe" pile rather than the
| "nope" pile.
| yau8edq12i wrote:
| If you replace "refuse" by "not bother to", the sentence
| suddenly becomes very believable. When you have dozens of
| resumes to sift through, and one applicant is difficult for
| no apparent reason, it's very easy not to bother. It's going
| to require a bit of effort to switch to the gitlab context
| and figure out the interface if the recruiter isn't used to
| it, which is annoying. Unless you already stand out for some
| positive reason, you don't really want to stand out for being
| annoying.
| danmur wrote:
| Well I personally am sick of seeing github profiles that
| are just a bunch of trash commits. List specific projects,
| what you contributed, and a link to who cares which service
| on your resume. Way easier to read
| marcosdumay wrote:
| Well if clicking a link to your Gitlab profile is more
| difficult than clicking a link to your Github profile...
| yes, that could happen.
|
| I have no idea how it could happen in practice. It's quite
| believable that there is some recruiter out there that has
| this kind of problem. But I do think it's quite safe to
| assume most of the tiny minority that will click on the
| link will get the same information from either one.
| thrdbndndn wrote:
| I just find GitHub's interface very intuitive and easy to use.
| Even GitLab isn't close despite being very similar; and it was
| miles ahead of sourceforge, Google Code etc.
|
| (This is from someone who is not a dev by profession and had no
| idea about version control at the time.)
| mdaniel wrote:
| One will never hear me defend GitLab's UI as "good" or
| "helpful" and for damn sure nowhere near _fast_ , but in
| their defense the number of things they need to provide an
| interface for is much, much larger than GitHub's. I could
| very easily see them making better use of "and the rest of
| it" to put the 80/20 front and center versus the "cheesecake
| factory menu" approach they have going now
| mardifoufs wrote:
| Is there any reason to use mailing lists for a new project? I
| totally get why you'd want to keep the mailing list structure for
| existing ones especially if your contributors are used to it, but
| it's such an off putting experience that I don't get why a newer
| project would want to use it. I read the article about why
| mailing lists are still good from sourcehut, but I think it just
| isn't convincing. So I'm genuinely wondering what I'm missing?
| I'm glad sourcehut is taking a different approach to other git
| services but I can't help but think that there's got to be a
| better way even if you don't want "GitHub style" pull requests.
| bigpeopleareold wrote:
| A mailing list is not the greatest thing in my opinion:
|
| 1. You have to subscribe to it 2. The interface for finding old
| issues can be bad (like long densely-packed threads with no
| search feature) 3. It forces me to manage my inbox (well,
| that's my problem)
|
| They can all be solvable though. I never used sourcehut - are
| these all the same issues?
| kwhitefoot wrote:
| > threads with no search feature
|
| If it's a mailing list then surely the mail is searchable
| using your choice of mail client?
| ryukafalz wrote:
| Presuming you were subscribed to the mailing list at the
| time the issue was reported. Which may be true for your own
| projects, but is much less likely for arbitrary projects
| that you may be looking to report an issue on yourself.
| theamk wrote:
| Not for emails that were sent before you subscribed.
|
| (and that means new contributors get the worse experience..
| not ideal)
| gray_-_wolf wrote:
| Lot of mailing lists offer the option to download mbox
| with old messages. So you can just download those for
| months/years when you were not subscribed.
| theamk wrote:
| they do? I don't think I've ever seen this in practice.
| And even if I do, having to download dozens of monthly
| archives is pretty annoying.
|
| (Also for example SourceForge only gives mbox files to
| administrators, not to regular users [0])
|
| [0] https://sourceforge.net/p/forge/documentation/Mailing
| %20List...
| gray_-_wolf wrote:
| I mostly read GNU mailing lists, and there mbox is
| offered https://lists.gnu.org/archive/mbox/ . Linux seems
| to offer a git repositories with the messages, which is
| bit annoying, but script-able.
|
| Well, it is not perfect, much still, the hassle is one-
| time, so meh.
| dzaima wrote:
| It's one-time for one project, but is a repeated hassle
| over multiple projects, and likely a different hassle at
| that.
| mariusor wrote:
| Sourcehut's specifically allows download of the full
| mailing list, or just the last 30 days.
|
| Threads can also be downloaded individually.
|
| And the search function is decent(ish) in the web
| interface.
| shp0ngle wrote:
| Mailing list is an open standard that anyone can join. Git even
| sends patches to it via git CLI.
|
| People talk about federation and decentralisation a lot, e-mail
| is sort of that.
|
| But it sucks UX-wise compared to github. Linux can afford it,
| because it will always have enough contributors anyway.
| martingxx wrote:
| I just interpret this whole thing as "developer realises their
| preferred set of trade-offs matches host A more than host B, so
| they are switching hosts". This happens fairly frequently in
| various directions for many different reasons.
|
| Slightly off topic, but related: I wish we could focus less on
| which git host is "best" and more on figuring out workable
| interoperability between them. Sadly, it seems less of a
| technical challenge and more a question of motive.
| nine_k wrote:
| But it's not about a _git_ host. It 's about a discussion /
| issues / code review host.
|
| All it takes to host git proper is a network-accessible machine
| with git and ssh. It's the trivial part.
|
| Making it convenient for you to communicate with other varied
| humans contributing to, or otherwise interested in the code, is
| the key differentiator. And apparently this is not the part
| SourceHut prioritizes. No wonder, because it's the hardest
| part.
| taion wrote:
| It's also not entirely a technical issue, anyway. In a vacuum
| the Sourcehut UX might be fine, but if people are used to
| GitHub-style UX, then they will have a hard time with
| Sourcehut and end up doing the wrong thing, like emailing the
| maintainer directly rather than using the mailing lists -
| through no fault of the mailing lists themselves!
| couchand wrote:
| > Making it convenient for you to communicate with other
| varied humans contributing to, or otherwise interested in the
| code, is the key differentiator. And apparently this is not
| the part SourceHut prioritizes. No wonder, because it's the
| hardest part.
|
| Just because you don't seem to understand or agree with
| another person's priorities doesn't mean that they don't have
| them. By my reading, contributors to SourceHut absolutely do
| prioritize tools that humans use to communicate, and in
| particular ones that have been demonstrated to support
| complex and nuanced technical discussions.
| nine_k wrote:
| This is great to know!
|
| SourceHut is new, and likely has a ton of competing
| priorities.
|
| Also, different groups have different preferred styles of
| communication. (E.g. chat vs email vs forums is a typical
| divide.) Different places offer different styles, and this
| is great, because one size often does not fit all.
|
| That said, most people are conditioned by using GitHub, and
| this sets their _default_ expectations. Then the network
| effect kicks in.
| couchand wrote:
| I'm not sure we have full data on the question, but by my
| own experiences the default expectation for most people
| regarding version control is copy the file and rename it.
| The default expectation for most people on collaboration
| tooling is sending an email. If they consider such things
| at all.
|
| We can easily define a niche within which GitHub-
| awareness can be presumed but it's certainly not "most
| people".
| nine_k wrote:
| I suspect the majority of people who come to GitHub with
| intentions other than contributing come either to skim
| the README for installation instructions, or to complain
| about a problem. They may not even know about git. This
| is the wide kind of GitHub-awareness, which still assumes
| a level of computer literacy above that of most people.
| busterarm wrote:
| Sourcehut is really targeting users who want an email-centric
| workflow, which it excels at. It's not trying to be(at)
| GitHub.
|
| You want it to be something that it isn't.
| martingxx wrote:
| I agree about the discussion / issues aspects. I suspect
| doing that interoperably would be hard or impossible because
| of the vastly different feature sets on different hosts.
|
| All I am looking for is a few interoperability features for
| the repositories themselves. In fact, if I were to describe
| the most important single feature, it would be something like
| this:
|
| I am able do some work in my repo hosted on host A, which was
| originally cloned from a repo on host B, and offer it back to
| the author on host B to merge if they wish. I'd like to be
| able to do this by notifying them (in a way integrated into
| my workflow) with the same kind of information that `git
| request-pull` generates. Importantly I would not need an
| account on host B for this. Possibly this might need some
| one-off setup on the original authors side, perhaps adding my
| repo as an remote.
|
| The use cases I have in mind here are mostly occasional
| contributions or minor changes. I don't think this would work
| well for people who are frequent major contributors - they
| would really need the discussion / issues aspects to
| collaborate effectively.
| pachico wrote:
| I am puzzled by the fact that he provides private lessons about
| life in general...
| YuukiRey wrote:
| Maybe it would be less puzzling if he called it coaching, since
| it sounds like that's what is it.
| moody__ wrote:
| I really wanted to like sourcehut, the premise of a code forge
| that you could submit PR's into that had enough-ish traction was
| nice, even if always a subsection of GitHub. At some point
| sourcehut had added a 9front runner to their ci system but it was
| a bit limited and never updated. So I took it upon myself to try
| and help out and fix this, make things better. Long story short
| on that was that I got lead on for 8 months with moving goal
| posts and then eventually told "sorry not interested".
|
| So without the benefit of being able to add code for things I
| care about, and without an interest in helping more niche
| software projects the benefits over GitHub seemed to just
| evaporate.
| necrotic_comp wrote:
| It's really a drag. I really really really want to like
| sourcehut and I like Drew Devault's stance on things, but it
| seems like it's one of those projects that's _almost_ there but
| not quite.
|
| Github is great. However, it would be wonderful if there were
| true viable alternatives, and if the global ecosystem played
| nicely together. (e.g. sourcehut took in patches from github
| and visa versa) I idly worry that with the state of things on
| the internet now, there's gonna eventually be a github-only
| version of git that ends up drifting and then _wham_ lock-in.
| 1337shadow wrote:
| gitea, drone
| ffsm8 wrote:
| Gitea is commercial now though. historically speaking, it's
| likely just a question of time until they switch to a more
| restrictive licence to extract more money.
|
| They also added their own CI system the other day. Haven't
| tried it myself, but I don't think drone-ci is necessary
| anymore.
| vetrom wrote:
| IMO Gitea is fairly protected against a 'random'
| relicensing, as the project does not use a contributor
| licensing agreement.
|
| While license and quality shenanigans can still happen,
| say if their technical oversight committee went bad, they
| cant do the same sort of rugpull done by projects that
| made contributors give all ownership interest to a single
| party.
|
| GOGS (gitea's origin project) is still around and keeps
| moving at its own pace, as well.
| LightFog wrote:
| Forgejo which powers codeberg recently hardforked from
| gitea and is looking like a nice alternative
| ffsm8 wrote:
| maybe, or maybe not. https://lwn.net/Articles/963608/
| imiric wrote:
| Reading through all this drama frankly demotivates me
| from using any of these projects.
|
| I'll stick to pushing to a bare Git repository via SSH
| for my personal projects. Plain Git works fine for that.
| Ringz wrote:
| Sad but true.
| ffsm8 wrote:
| Drama usually centeres around a certain kind of person
| after all, and Gitea literally forked with a shitton of
| drama back in the day.
|
| While the gogs developer only set the record straight and
| moved on with his life, the Gitea forkers kept drumming
| up controversy for weeks
| MonkeyClub wrote:
| Ditto.
|
| An "ssh init --bare" is enough, and after the first pull
| everything's the same.
|
| But I'm generally of the mind that not everything needs
| to be public all the time, so I'm OK with not having a
| wiki and issues on such bare repos.
| mappu wrote:
| Gitea is as commercial as sourcehut.
|
| Gitea's CI was marked stable in 1.19 in March 2023.
| mdaniel wrote:
| I'm not trying to start trouble, I'm genuinely interested in
| hearing why GitLab is not a true viable alternative. I'll be
| upfront that I'm a fanboi (and now a shareholder) but my
| question is in good faith since it interests me to hear the
| different perspectives and requirements
| necrotic_comp wrote:
| From my experience with Gitlab, it feels like Github but
| slightly worse so things aren't exactly in the place you
| expect them to be. Sourcehut is completely different, so
| (for better or worse) any user knows they have to adjust
| their approach.
| arp242 wrote:
| GitLab's free plan is pretty limited; one of the nice
| things about GitHub is that the free/open source plan is
| actually sufficient for the vast majority of projects. And
| with the cheapest plan being $29/user per month that's not
| really an option for personal accounts or open source
| projects. GitLab's pricing strategy has been discussed on
| HN extensively before, and very few people seemed willing
| to pay that. It's strongly focused on business cases (and
| even for that, it's actually quite expensive).
|
| Other than that, I think it's "viable" in the sense of "it
| works", but I hate using it. The UI is _SLOW_ and overly
| complex. And lots of things don 't work well if you zoom
| things to make text larger. So even without all the pricing
| plan woes I wouldn't want to use it.
| whalesalad wrote:
| sourcehut UI is atrocious I'm not sure why anyone uses it when
| codeberg, GitHub and GitLab exist.
| silent_cal wrote:
| Is this the most Hacker News title ever?
| mdaniel wrote:
| document.title += " in Rust using ChatGPT"
| slow_typist wrote:
| If you have a choice what to use, I can only recommend to compare
| the terms and conditions of gitlab, GitHub and sourcehut. Last
| time I checked, sourcehut's terms were much better for the
| customer.
|
| As an example, check out paragraphs 8.6 and 10.2 here:
|
| https://handbook.gitlab.com/handbook/legal/subscription-agre...
| johno2 wrote:
| hope this doesn't sound sarcastic, what's the problem with
| github?
| johno2 wrote:
| i've always defaulted to github, what are some the reasons not to
| use it?
| josebama wrote:
| And why not use Codeberg instead of GitHub? AFAIK it solves the
| problems the post mentions while staying in a libre platform
| blacklight wrote:
| I raised many of the author's point about Sourcehut several
| times. I'm an, enthusiastic FOSS supporter who has always
| advocated for alternatives to Github. But Sourcehut seems to take
| the worst out of everything. It strips down all the features,
| provides a web interface that seems to come out of the 1990s,
| removes anything that is even vaguely interactive in favour of
| emails, and it turns reviews and PRs a mess of emails and patch
| files that is impossible to browse.
|
| Seriously, when we say that Github is bad, it doesn't mean that
| the solution is to get back to the software development cycles of
| the early 2000s and throw out of the window all the innovations
| made in the past two decades.
|
| Sourcehut's extremely elitist and proudly feature-poor approach
| is only pushing away potential users and contributors, and I
| don't think it's doing a good favour to the community.
|
| I would advise the author to give Forgejo a try (Gitea has almost
| become fully enshittified with its business plans and vision, so
| I wouldn't recommend it to anyone anymore). Everything is very
| similar to Github, but FOSS and self-hosted, and it takes a tiny
| fraction to run than the resources required by that shapeless
| beast called Gitlab.
| busterarm wrote:
| > I raised many of the author's point about Sourcehut several
| times. I'm an, enthusiastic FOSS supporter who has always
| advocated for alternatives to Github. But Sourcehut seems to
| take the worst out of everything. It strips down all the
| features, provides a web interface that seems to come out of
| the 1990s, removes anything that is even vaguely interactive in
| favour of emails, and it turns reviews and PRs a mess of emails
| and patch files that is impossible to browse.
|
| That's exactly what its goals are. Sourcehut is for people who
| want to do everything out of email. All of this is a feature.
| Stop trying to make it GitHub. If it's not for you, it's not
| for you.
|
| For some of us, Sourcehut is a revelation. Sourcehut works for
| its users rather than its users work for it.
| pinto-marco wrote:
| As someone who's found Sourcehut to be a great fit for my
| workflow, I fully agree that it's been a "revelation."
| jmclnx wrote:
| I left githup due to how Microsoft enabled 2FA, now back to anon
| ftp via gemini.
|
| I would like to find something like github and was thinking about
| sourcehut. But now I may think of looking elsewhere. But to be
| honest, anon ftp is good enough for me since my things are about
| as far from earth shattering as something can get :)
| brianzelip wrote:
| Thanks Drew et al for Sourcehut, Hare Lang, principles, and more!
| Decabytes wrote:
| I love Emacs and have used it since the start of my programming
| career. It is so powerful and I consider it more like a portable
| programming environment than a text editor. But I find it's
| performance frustratingly slow. I accept that it will never be as
| fast as Vim, but when it takes as long or longer to boot up as a
| regular IDE it makes me question why I'm not using that. Plus
| there are large json files I can open up no problem in NeoVim
| that Emacs chokes on.
|
| With that being said, there is no program that has come along
| that is a sufficient modern replacement for Emacs like Neovim is
| for Vim. Unless you've used Emacs heavily then it's just hard to
| understand. And it's not just being able to use a terminal or
| write some markdown/org notes in it.
|
| It's built in support for IRC. Reading email. Emacs Speaks
| Statistics. It's being able to make functions and bind just about
| anything to a set of key chords. It's using things like
| restclient to send rest requests, and many other awesome things.
| Using Emacs kind of feels like programming in Smalltalk in a way.
| ashton314 wrote:
| > but when it takes as long or longer to boot up as a regular
| IDE it makes me question why I'm not using that
|
| How many packages do you have? I have over 200 enabled but my
| startup time is consistently >2 seconds on average. The `use-
| package` macro really helps here. (And now it's built-in to
| Emacs 29!)
|
| Yeah, performance is a bit of an issue. But recent development
| has put it on a good trajectory with native comp and better
| JSON handling.
| teddyh wrote:
| For startup speed, use an Emacs server. For speed in JSON
| files, the new fixes for long lines in Emacs 29 should improve
| the situation markedly.
| gaws wrote:
| > I accept that it will never be as fast as Vim, but when it
| takes as long or longer to boot up as a regular IDE it makes me
| question why I'm not using that.
|
| You can significantly increase startup speed by running the
| emacs daemon on boot and using `emacsclient` for each new
| instance.
| MeowKing wrote:
| I cannot see active development of Sourcehut. You can see the
| latest closed `beta` label is two years ago:
| https://todo.sr.ht/~sircmpwn/todo.sr.ht?search=status%3Aclos...
| aesh2Xa1 wrote:
| That's a to-do list. You've filtered tickets for two tags
| (status:closed label:beta).
|
| I think you can look at the actual project development here:
| https://git.sr.ht/~sircmpwn?search=sr.ht
|
| If you're just after "the number/recency of closed tickets
| equates to development activity," then you could look here:
| https://todo.sr.ht/~sircmpwn/todo.sr.ht?search=status%3Aclos...
| sph wrote:
| The issue I had with Sourcehut was minor yet very annoying: My
| memory might fail me, but I remember I had a hard time navigating
| from a project's home page to its source code or mailing list.
| IIRC they are hosted on separate subdomains, and not linked with
| each other, which is terrible UX. I had to manually change the
| URL host to git.sr.ht to get to the code.
|
| Also, user error, I paid for it to learn that they forbid
| commercial projects -- I like my code host to be free of any
| restrictions. Sadly Codeberg is the same, so the choice is either
| the awful Git(Hub|Lab), or self hosting.
|
| I guess my payment served as donation to a FOSS-friendly service,
| which isn't too bad karma-wise.
| llmblockchain wrote:
| I tangoed with Fossil[1].. it was a nice experience. In the end,
| I self host everything in bare git repos on my own server. I
| don't have or want contributors so it's fine... plus, I have the
| server in the cloud anyway for backups, etc.
|
| [1]: https://www.fossil-scm.org
| aidenn0 wrote:
| > Users replying to mailing list threads frequently do not "reply
| to all", so the filter I have for SourceHut lists does not apply
| and my inbox is noisy again.
|
| The major webmail clients defaulting to "Reply to Sender" rather
| than "Reply to List" really broke mailing lists as a sane
| workflow for corroboration. Most traditional e-mail clients will
| reply to the list if you hit the "reply" button.
|
| This is probably due to people accidentally sending company-wide
| replies to announcement lists (e.g. I did this when our company
| wide e-mail target changed from an alias to a list).
|
| I'm guessing most list-servers don't make it easy to put a reply-
| to header on announcement lists where list-reply is typically
| wrong? Or if they do, most list administrators don't know about
| it?
|
| I'm not sure I have a point to this other than "this is why we
| can't have nice things" as I find e-mail to be one of the better
| collaboration tools; everybody can use the client they prefer,
| and for the most part, things "just work" which is rather
| amazing.
| blacklion wrote:
| Good mailing list management software substitute list address
| to "Reply-To" header, so even simple "Reply" works fine (all
| known MUIs respect "Reply-To").
|
| But it is typically breaks DKIM signature :-(
| urda wrote:
| I really want forgejo and their federation to make a dent in the
| git world.
___________________________________________________________________
(page generated 2024-03-12 23:02 UTC)