9 ms·

> Welcome to sourcehut! This suite of open source tools is the software development platform you've been waiting for. > Git and Mercurial hosting, mailing l

> Welcome to sourcehut! This suite of open source tools is the software development platform you've been waiting for. > Git and Mercurial hosting, mailing lists, bug tracking, continuous integration, and more > Absolutely no tracking or advertising > All features work without JavaScript > 100% free and open source software For someone who is not familiar with sourcehut what other benefits does it provide over gitlab? (Don't get me wrong i absolutely like that every feature works without javascript, i am just curious)

mahkoh 6y ago
I've been using sr.ht to run unit tests on OpenBSD. Performance has been excellent and prices are low (from $2/month.)
rainingcatndogs 6y ago
I haven't used them but I think the most important benefit is collaboration (sending pull requests etc...) is done via email and thus is less centralised platfomr than github/gitlab which uses their own mechanisms.
- brianzelip 6y ago
  Here's a video on the email workflow by Sourcehut's author, https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...
  - dnr 6y ago
    Wow, that video feels pretty disingenuous. - The whole premise assumes that you need to make a new account for each project you contribute to, because they're hosted on individual gitea or similar instances. Some are, but let's be honest, the vast majority of projects are currently hosted on a very small set of services (github, gitlab, one or two others), and most developers will already have accounts on them. (I get that part of the goal is to eliminate dependency on large code hosting services, and I agree with that. But we should do that with federation standards so people can use individual gitea/whatever instances without making accounts on all of them, not by traveling back in time 20 years.) - He spends a lot of time complaining about silly password requirements. The complaint is valid but not relevant to the comparison. - The graylisting thing is an own-goal, sorry. - He complains that forking the repo and creating the PR require context-switching from the cli to the web and back, but there are cli tools that can fork repos and create PRs for you on github, gitlab, etc. to fix that. - Let's allow that submitting a single patch, starting from outside the project, is faster for the contributor with an email workflow. But that's a tiny part of the process. There's a lot of things that happen after that patch: the project maintainers have to triage it, they have to review it, make comments on specific lines of the diff, or sometimes on line that aren't part of the diff, and then indicate that the submitter should make changes and try again. The submitter then has to make changes and submit it again. The reviewers, at that point, will probably want to see the diff between the first and second revision. Triage: The github/gitlab UI for this is not great but acceptable. Viewing a mailing list in my email client mixes discussion and patches. I can't mark threads with labels or priorities. I can't assign a particular review to a particular person and have it show up in their todo list. Review: Sure, you can reply to a patch posted on a list and intersperse comments, but web uis for code review are pretty decent these days. You can easily see much more of the context when required, your comments and replies on specific lines get threaded even across revisions of the code, each comment thread can have an individual "done" indicator, etc. The review as a whole has a global status of whose turn it is to take an action next. All of these seem much harder by email; you end up just using a lot of conventions. You can use a web-based review tool with email-based patches, of course, but... why bother? If you're doing web-based review, just do the whole workflow there and it'll be a lot simpler and easier to understand. Resubmit: Resubmitting a patch set by email posts brand new diffs. How do I see the differences between different versions of the patch? Sure, I can rig up a bunch of scripts to do this, but is it integrated with the review tool, etc.? - What happens when I become a maintainer? I have to sign up for a new mailing list. And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows.
    - tristan957 6y ago
      When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI. You can mark emails with labels though depending on your Email client. The onus is on you. SourceHut also supports adding labels to SourceHut tickets through email I believe. You can assign a review to someone. You literally just CC them on the email. > And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows. If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it.
      - dnr 6y ago
        > When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI. I used "hub" back in 2013, so it's at least that old. It wasn't official, though I'm not sure why that makes any difference. Searching on google for "gitlab cli clients" shows a bunch, at least some of which have histories dating back to 2013. > You can mark emails with labels though depending on your Email client. The onus is on you. But those are local to you and your client. I'm talking about labels that are shared state, that the whole project and the public can see. Those are widely used on github for categorization, triage, communicating the stage of the review, etc. They're undeniably useful to teams. You can put all that information in English text in email bodies, but then everyone has to read a whole thread to understand the state of things, and there's more potential for confusion. > You can assign a review to someone. You literally just CC them on the email. Same thing: how do I assign a reviewer so that everyone can quickly and unambiguously see who is assigned to review that PR/patch set? With PR metadata, this is trivial. With mailing lists, it depends on social conventions. > If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it. Thank you for insulting my intelligence. I didn't say it's hard, I said that it adds friction. I'm not claiming that the web-based PR and review UI works for everyone; obvious email works fantastically well for Linux (though I'm not convinced something else couldn't work even better). I do think it works very well for small to medium size projects (which are most projects, after all). An accurate comparison of the strengths and weaknesses of each model would need to be much more thorough and look at the entire development cycle, for projects of different sizes. I don't agree that that video was anything like that. It seemed like a cheap shot, based on one cherry-picked metric (time to submit an initial patch starting from nothing) that's not particular representative.
eatonphil 6y ago
I haven't used Sourcehut, but almost no other CI service I know of provides FreeBSD or OpenBSD runners.
arch-ninja 6y ago
I count simplicity as a feature. Not knocking GitLab, from a business perspective they provide the same capability.
mfsch 6y ago
I think the most consequential difference is that sourcehut is built on top of existing tools for distributed development with the goal of avoiding lock-in. Instead of replacing the distributed tools traditionally used in FLOSS development (mailing lists, patches) with centralized ones (issue tracker, pull requests), the goal is to provide an interface that makes it easier to use the tools of the distributed model.
- __henil 6y ago
  I have known that development of linux, git was done over email, And always wondered how PR worked there, but I never took time to know how actually it was done. For someone like me this[0] looks like a good start. [0]: https://git-send-email.io/ https://git-send-email.io/
shakna 6y ago
Everything is modular and "vendorless". To put it another way, if I want to use the CI, then I can drag in sources from anyone. GitHub, GitLab, raw HTTP, etc. Multiple projects. Then build against not just the usual suspects, but also BSD. If I want to open up an issue tracker without it being connected to any project, I can go ahead and do that. I can also make it frictionless and have user's without an account go ahead and open up/comment on issues. And I can self-host each of these "modules" myself, with full documentation on how to do that.
njkleiner 6y ago
I imagine the builtin email support might be the single biggest selling point, if you're into that kind of workflow... Also, the simplicity is certainly appreciated.
slmjkdbtl 6y ago
Not a sourcehut power user myself but for me personally the user experience and aesthetics is way superior. The web client made me think about how tech directly relates to user experience, by having no javascript and minimal style means there's less chance to fuck up, everything is super responsive and simple, there are a lot of features but very well sorted and clear. Also I always prefer softwares that have a lead dev who I respect.
- alexwennerberg 6y ago
  > no javascript To be clear, sourcehut does occasionally use JavaScript, it’s just very conservative and optional.
  - gray_-_wolf 6y ago
    > and optional. This is imho the most important part.
- deleted 6y ago
  [deleted]
hprotagonist 6y ago
ideological purity.
busterarm 6y ago
It's actually open source (instead of the source available/open core nonsense). Whether that matters to you or your business is a different story.
- SulfurHexaFluri 6y ago
  The open source section of Gitlab is very powerful and perfectly usable on its own.
  - busterarm 6y ago
    The problem with open-core licenses is that you always have to weigh the risk of whether the feature you depend on will get pulled into the paid license, pegging you on a release forever without updates. If you look at the direction of most popular products that are open-core, you have a spectrum from ElasticSearch (Slightly hobbled, the free x-pack features that you WILL use in production put you at risk of dipping into paid uses and in violation. running Amazon's fork/open distro is strictly better) to Neo4j (completely unusable in a production context without a paid, mega-expensive, cost-of-a-nice-house-per-year license. No clustering, can't be effectively monitored, none of the tuning knobs that you will need as your dataset grows). Open-core licenses are entirely hostile to the spirit of OSS and just pay it lip service to delude the ignorant.
wpietri 6y ago
There's a nice feature list on their home page: https://sourcehut.org/ https://sourcehut.org/ The one that made me go "oooh!" is this: Powerful continuous integration - Runs fully virtualised builds on various Linux distros and BSDs - Submit ad-hoc jobs without pushing to your repository - Post-build triggers for email, webhooks, etc - Log in with SSH after build failures to investigate further Submitting jobs without pushing and logging in after failed builds are two features that I didn't know I wanted. But now that I see them, I really want them.
- sytse 6y ago
  The parent asked which features of sourcehut are not in GitLab. I think manual triggers are in GitLab https://forum.gitlab.com/t/gitlab-ci-run-pipeline-manually/13797 https://forum.gitlab.com/t/gitlab-ci-run-pipeline-manually/1... and I assume post build triggers are. Logging in via SSH seems useful although that would mean keeping the machine running after a failed build.
  - eatonphil 6y ago
    Somewhat related to this thread: a frustration I have with most CI systems is how hard it can be to reproduce the run locally using (ideally all of the) same configuration. For example, Gitlab CI has a local runner but it's not really first class, definitely isn't kept up to date with the real runners. It seems like it's more of a recreation of a job system based off of (an older version of) Gitlab CI configuration files. Circle CI has a more decent story around this if I remember correctly. But first-class support for local reproduction of CI runs is the kind of thing I'd like to see as table stakes today. It can be challenging to debug certain things in the live CI system for developers without being able to recreate locally (otherwise you have to bring in the team that manages the CI system to help them debug with you which takes time).
    - Macha 6y ago
      The trick is to do as much as possible outside the CI system. Ideally, each step should just call a single script, Makefile command, or your language's build tool equivalent.
nathcd 6y ago
To add to others' comments, another nice detail is that you can simply push to a non-existing repository to create it, rather than having to first create it through the web ui.
- judge2020 6y ago
  Sounds like a good way to accidentally create a repo, hopefully it’s private by default.
  - ddevault 6y ago
    It gives you a link to click to confirm the new repository creation, or you can use git push options to set the visibility and description (git push -o visibility=public -o description="my cool repo")
  - alisonkisk 6y ago
    One of many ways that amateur open system are vulnerable to fraud and abuse once they lose their security-via-obscurity
    - MaxBarraclough 6y ago
      1. Please don't do this. HackerNews is not the place to hurl empty insults. 2. I'm not sure if your intent was to insult Drew DeVault personally, or to insult the SourceHut project. Drew has given us no reason to doubt his competence, and SourceHut is already accepting payments. Neither sense of the word amateur applies here. 3. That's not what security-by-obscurity means. It would be a bad default, instead, but as Drew has since explained, it's not even that. Unless you explicitly request creation of a public repo, you won't get a public repo.
musicmatze 6y ago
The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see nixos/nixpkgs) because it does not allow horizontal scaling at all - thousands of "PRs" open, nobody feeling responsible and slowdown overall. Having a tool that provides only an "overlay" over the workflow git wants to be used with, and that's what sourcehut is, but not a replacement for it (which is what github is), is refreshing and promising!
- throwaway894345 6y ago
  Can you elaborate on how sourcehut or other git workflows scale better?
  - ddevault 6y ago
    You may find this helpful: https://drewdevault.com/2020/09/02/Linux-development-is-profoundly-distributed.html https://drewdevault.com/2020/09/02/Linux-development-is-prof...
- Znafon 6y ago
  It's not "an abomination of a workflow", and it's very possible for communities to have difficulties in scaling with a mailing list and have a bus factor of 1 despite plenty of movement on the mailing list. Git also had a git-request-pull command that prepares a mail with the same information that you can find in a pull request on GitHub even before GitHub existed. There is no "one true way" to Git and if organization to adapt their workflow to their needs they can have issues both with mailing lists and the centralised forge model.
- ChickeNES 6y ago
  > The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. Welp, that puts me off using it entirely sadly. I hate dealing with mailing lists and refuse to contribute to any project that requires dealing with text patches in 2020. Like it or not, the pull request model is simply easier to deal with and is easier for new users to use.

mahkoh 6y ago

I've been using sr.ht to run unit tests on OpenBSD. Performance has been excellent and prices are low (from $2/month.)

rainingcatndogs 6y ago

I haven't used them but I think the most important benefit is collaboration (sending pull requests etc...) is done via email and thus is less centralised platfomr than github/gitlab which uses their own mechanisms.

brianzelip 6y ago
Here's a video on the email workflow by Sourcehut's author, https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...
- dnr 6y ago
  Wow, that video feels pretty disingenuous. - The whole premise assumes that you need to make a new account for each project you contribute to, because they're hosted on individual gitea or similar instances. Some are, but let's be honest, the vast majority of projects are currently hosted on a very small set of services (github, gitlab, one or two others), and most developers will already have accounts on them. (I get that part of the goal is to eliminate dependency on large code hosting services, and I agree with that. But we should do that with federation standards so people can use individual gitea/whatever instances without making accounts on all of them, not by traveling back in time 20 years.) - He spends a lot of time complaining about silly password requirements. The complaint is valid but not relevant to the comparison. - The graylisting thing is an own-goal, sorry. - He complains that forking the repo and creating the PR require context-switching from the cli to the web and back, but there are cli tools that can fork repos and create PRs for you on github, gitlab, etc. to fix that. - Let's allow that submitting a single patch, starting from outside the project, is faster for the contributor with an email workflow. But that's a tiny part of the process. There's a lot of things that happen after that patch: the project maintainers have to triage it, they have to review it, make comments on specific lines of the diff, or sometimes on line that aren't part of the diff, and then indicate that the submitter should make changes and try again. The submitter then has to make changes and submit it again. The reviewers, at that point, will probably want to see the diff between the first and second revision. Triage: The github/gitlab UI for this is not great but acceptable. Viewing a mailing list in my email client mixes discussion and patches. I can't mark threads with labels or priorities. I can't assign a particular review to a particular person and have it show up in their todo list. Review: Sure, you can reply to a patch posted on a list and intersperse comments, but web uis for code review are pretty decent these days. You can easily see much more of the context when required, your comments and replies on specific lines get threaded even across revisions of the code, each comment thread can have an individual "done" indicator, etc. The review as a whole has a global status of whose turn it is to take an action next. All of these seem much harder by email; you end up just using a lot of conventions. You can use a web-based review tool with email-based patches, of course, but... why bother? If you're doing web-based review, just do the whole workflow there and it'll be a lot simpler and easier to understand. Resubmit: Resubmitting a patch set by email posts brand new diffs. How do I see the differences between different versions of the patch? Sure, I can rig up a bunch of scripts to do this, but is it integrated with the review tool, etc.? - What happens when I become a maintainer? I have to sign up for a new mailing list. And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows.
  - tristan957 6y ago
    When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI. You can mark emails with labels though depending on your Email client. The onus is on you. SourceHut also supports adding labels to SourceHut tickets through email I believe. You can assign a review to someone. You literally just CC them on the email. > And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows. If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it.
    - dnr 6y ago
      > When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI. I used "hub" back in 2013, so it's at least that old. It wasn't official, though I'm not sure why that makes any difference. Searching on google for "gitlab cli clients" shows a bunch, at least some of which have histories dating back to 2013. > You can mark emails with labels though depending on your Email client. The onus is on you. But those are local to you and your client. I'm talking about labels that are shared state, that the whole project and the public can see. Those are widely used on github for categorization, triage, communicating the stage of the review, etc. They're undeniably useful to teams. You can put all that information in English text in email bodies, but then everyone has to read a whole thread to understand the state of things, and there's more potential for confusion. > You can assign a review to someone. You literally just CC them on the email. Same thing: how do I assign a reviewer so that everyone can quickly and unambiguously see who is assigned to review that PR/patch set? With PR metadata, this is trivial. With mailing lists, it depends on social conventions. > If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it. Thank you for insulting my intelligence. I didn't say it's hard, I said that it adds friction. I'm not claiming that the web-based PR and review UI works for everyone; obvious email works fantastically well for Linux (though I'm not convinced something else couldn't work even better). I do think it works very well for small to medium size projects (which are most projects, after all). An accurate comparison of the strengths and weaknesses of each model would need to be much more thorough and look at the entire development cycle, for projects of different sizes. I don't agree that that video was anything like that. It seemed like a cheap shot, based on one cherry-picked metric (time to submit an initial patch starting from nothing) that's not particular representative.

eatonphil 6y ago

I haven't used Sourcehut, but almost no other CI service I know of provides FreeBSD or OpenBSD runners.

arch-ninja 6y ago

I count simplicity as a feature. Not knocking GitLab, from a business perspective they provide the same capability.

mfsch 6y ago

I think the most consequential difference is that sourcehut is built on top of existing tools for distributed development with the goal of avoiding lock-in. Instead of replacing the distributed tools traditionally used in FLOSS development (mailing lists, patches) with centralized ones (issue tracker, pull requests), the goal is to provide an interface that makes it easier to use the tools of the distributed model.

__henil 6y ago
I have known that development of linux, git was done over email, And always wondered how PR worked there, but I never took time to know how actually it was done. For someone like me this[0] looks like a good start. [0]: https://git-send-email.io/ https://git-send-email.io/

shakna 6y ago

Everything is modular and "vendorless". To put it another way, if I want to use the CI, then I can drag in sources from anyone. GitHub, GitLab, raw HTTP, etc. Multiple projects. Then build against not just the usual suspects, but also BSD. If I want to open up an issue tracker without it being connected to any project, I can go ahead and do that. I can also make it frictionless and have user's without an account go ahead and open up/comment on issues. And I can self-host each of these "modules" myself, with full documentation on how to do that.

njkleiner 6y ago

I imagine the builtin email support might be the single biggest selling point, if you're into that kind of workflow... Also, the simplicity is certainly appreciated.

slmjkdbtl 6y ago

Not a sourcehut power user myself but for me personally the user experience and aesthetics is way superior. The web client made me think about how tech directly relates to user experience, by having no javascript and minimal style means there's less chance to fuck up, everything is super responsive and simple, there are a lot of features but very well sorted and clear. Also I always prefer softwares that have a lead dev who I respect.

alexwennerberg 6y ago
> no javascript To be clear, sourcehut does occasionally use JavaScript, it’s just very conservative and optional.
- gray_-_wolf 6y ago
  > and optional. This is imho the most important part.
deleted 6y ago
[deleted]

hprotagonist 6y ago

ideological purity.

busterarm 6y ago

It's actually open source (instead of the source available/open core nonsense). Whether that matters to you or your business is a different story.

SulfurHexaFluri 6y ago
The open source section of Gitlab is very powerful and perfectly usable on its own.
- busterarm 6y ago
  The problem with open-core licenses is that you always have to weigh the risk of whether the feature you depend on will get pulled into the paid license, pegging you on a release forever without updates. If you look at the direction of most popular products that are open-core, you have a spectrum from ElasticSearch (Slightly hobbled, the free x-pack features that you WILL use in production put you at risk of dipping into paid uses and in violation. running Amazon's fork/open distro is strictly better) to Neo4j (completely unusable in a production context without a paid, mega-expensive, cost-of-a-nice-house-per-year license. No clustering, can't be effectively monitored, none of the tuning knobs that you will need as your dataset grows). Open-core licenses are entirely hostile to the spirit of OSS and just pay it lip service to delude the ignorant.

wpietri 6y ago

There's a nice feature list on their home page: https://sourcehut.org/ https://sourcehut.org/ The one that made me go "oooh!" is this: Powerful continuous integration - Runs fully virtualised builds on various Linux distros and BSDs - Submit ad-hoc jobs without pushing to your repository - Post-build triggers for email, webhooks, etc - Log in with SSH after build failures to investigate further Submitting jobs without pushing and logging in after failed builds are two features that I didn't know I wanted. But now that I see them, I really want them.

sytse 6y ago
The parent asked which features of sourcehut are not in GitLab. I think manual triggers are in GitLab https://forum.gitlab.com/t/gitlab-ci-run-pipeline-manually/13797 https://forum.gitlab.com/t/gitlab-ci-run-pipeline-manually/1... and I assume post build triggers are. Logging in via SSH seems useful although that would mean keeping the machine running after a failed build.
- eatonphil 6y ago
  Somewhat related to this thread: a frustration I have with most CI systems is how hard it can be to reproduce the run locally using (ideally all of the) same configuration. For example, Gitlab CI has a local runner but it's not really first class, definitely isn't kept up to date with the real runners. It seems like it's more of a recreation of a job system based off of (an older version of) Gitlab CI configuration files. Circle CI has a more decent story around this if I remember correctly. But first-class support for local reproduction of CI runs is the kind of thing I'd like to see as table stakes today. It can be challenging to debug certain things in the live CI system for developers without being able to recreate locally (otherwise you have to bring in the team that manages the CI system to help them debug with you which takes time).
  - Macha 6y ago
    The trick is to do as much as possible outside the CI system. Ideally, each step should just call a single script, Makefile command, or your language's build tool equivalent.

nathcd 6y ago

To add to others' comments, another nice detail is that you can simply push to a non-existing repository to create it, rather than having to first create it through the web ui.

judge2020 6y ago
Sounds like a good way to accidentally create a repo, hopefully it’s private by default.
- ddevault 6y ago
  It gives you a link to click to confirm the new repository creation, or you can use git push options to set the visibility and description (git push -o visibility=public -o description="my cool repo")
- alisonkisk 6y ago
  One of many ways that amateur open system are vulnerable to fraud and abuse once they lose their security-via-obscurity
  - MaxBarraclough 6y ago
    1. Please don't do this. HackerNews is not the place to hurl empty insults. 2. I'm not sure if your intent was to insult Drew DeVault personally, or to insult the SourceHut project. Drew has given us no reason to doubt his competence, and SourceHut is already accepting payments. Neither sense of the word amateur applies here. 3. That's not what security-by-obscurity means. It would be a bad default, instead, but as Drew has since explained, it's not even that. Unless you explicitly request creation of a public repo, you won't get a public repo.

musicmatze 6y ago

The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see nixos/nixpkgs) because it does not allow horizontal scaling at all - thousands of "PRs" open, nobody feeling responsible and slowdown overall. Having a tool that provides only an "overlay" over the workflow git wants to be used with, and that's what sourcehut is, but not a replacement for it (which is what github is), is refreshing and promising!

throwaway894345 6y ago
Can you elaborate on how sourcehut or other git workflows scale better?
- ddevault 6y ago
  You may find this helpful: https://drewdevault.com/2020/09/02/Linux-development-is-profoundly-distributed.html https://drewdevault.com/2020/09/02/Linux-development-is-prof...
Znafon 6y ago
It's not "an abomination of a workflow", and it's very possible for communities to have difficulties in scaling with a mailing list and have a bus factor of 1 despite plenty of movement on the mailing list. Git also had a git-request-pull command that prepares a mail with the same information that you can find in a pull request on GitHub even before GitHub existed. There is no "one true way" to Git and if organization to adapt their workflow to their needs they can have issues both with mailing lists and the centralised forge model.
ChickeNES 6y ago
> The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. Welp, that puts me off using it entirely sadly. I hate dealing with mailing lists and refuse to contribute to any project that requires dealing with text patches in 2020. Like it or not, the pull request model is simply easier to deal with and is easier for new users to use.