Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accepting PRs/patches from non-Github users #7901

Open
rubenwardy opened this issue Nov 26, 2018 · 13 comments
Open

Accepting PRs/patches from non-Github users #7901

rubenwardy opened this issue Nov 26, 2018 · 13 comments

Comments

@rubenwardy
Copy link
Member

@rubenwardy rubenwardy commented Nov 26, 2018

GitHub uses proprietary Javascript with a unreleased backend. This results in some people being unwilling to use it. For those who use Github but with Javascript disabled, it's possible to comment but it's not possible to open a PR.

There are quite a few skilled people we could be missing out on, so it's worth having an alternative available. There are quite a few possibilities for this, including archaic methods such as mailing lists, but I'd prefer a solution which would automatically open a PR and allow submitting new content to it.

cc/ @Wuzzy2

Related: #7412

Proposals:

  • PRs on Gitlab, mirror to Github
  • Create PRs from a Minetest fork and branch via an email or website. Users would push to their fork on github as usual to update the PR
  • Create PRs by emailing patches, and having them opened on Github by a bot
  • Switch to Gitlab/etc (flamewar starting in 3.. 2.. 1..)
@Wuzzy2

This comment has been minimized.

Copy link
Contributor

@Wuzzy2 Wuzzy2 commented Nov 26, 2018

I'm not tending towards any particular solution for now. But I favor any solution that reduces Minetest's and contributor's dependency on proprietary code.

Note it's not just PRs that are broken, there are also some other subtle features that are broken. Like comments on code lines, adding a reaction (those emojis), and mayhaps a few other things I forgot.

Until a solution is found, I probably will maintain a fork somewhere else and ask devs to merge when the time has come. I haven't prepared such a fork yet.

@Fixer-007

This comment has been minimized.

Copy link
Contributor

@Fixer-007 Fixer-007 commented Nov 27, 2018

Also noticed github on FF52 ESR (pre quantum) was suddenly crippled and warning issue, functionality that worked just fine suddenly disabled (it seems), like editing posts, etc.

@paramat

This comment has been minimized.

Copy link
Member

@paramat paramat commented Nov 28, 2018

My opinion: Whatever is simplest for MT core devs to set up and maintain (since we have very limited time). 1 or 3 sound best, 2 sounds possibly complex. Not 4 :) not for this reason only anyway, it may happen for other reasons eventually though.

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Dec 5, 2018

Since 1 doesn't seem to involve having to write bot code, it's probably best (I'd prefer 4 but...). I'm eager to see this happening. I will probably drop this user before the end on the year.

@Calinou

This comment has been minimized.

Copy link
Member

@Calinou Calinou commented Dec 5, 2018

For those who use Github but with Javascript disabled, it's possible to comment but it's not possible to open a PR.

Actually, the open source hub CLI can be used to do so 😃

git clone https://github.com/minetest/minetest.git
cd minetest
hub fork
git checkout -b some-branch-name
# Do stuff
git add . && git commit -m "Fix a bug"
git push <username> # Replace with your GitHub username
hub pull-request # $EDITOR will open, fill in a message, save and quit

It can also be used to list and create issues:

# List issues
hub issue

# Show an issue (including comments)
hub issue show 1

# List pull requests
hub pr list
@nerzhul

This comment has been minimized.

Copy link
Member

@nerzhul nerzhul commented Dec 18, 2018

i think switching to gitlab.com can be nice, as our gitlab mirror provides many useful features, like commit based builds (with debian, ubuntu, fedora, docker, windows packages), whereas github provides travis the old unmaintained tool :(
Also gitlab can be nice for publishing docs easily though the gitlab pages which are less restrictive than the github pages (from my point of view)
Last, Gitlab has subgroups, can be nice to have community mods inside minetest/mods groups directly if we want to have a better community sharing

@Calinou

This comment has been minimized.

Copy link
Member

@Calinou Calinou commented Dec 18, 2018

i think switching to gitlab.com can be nice, as our gitlab mirror provides many useful features, like commit based builds (with debian, ubuntu, fedora, docker, windows packages), whereas github provides travis the old unmaintained tool :(

It's possible to deploy continuous releases using any CI system; you just need GitHub API access. Tools like gothub make this easier, see this script where I used it on Azure Pipelines for an example.

Also gitlab can be nice for publishing docs easily though the gitlab pages which are less restrictive than the github pages (from my point of view)

What kind of restrictions do you have in mind? Even though it's more involved, it's possible to use static site generators other than Jekyll on GitHub Pages by building the site files on CI and pushing them to a branch on every commit.

@nerzhul

This comment has been minimized.

Copy link
Member

@nerzhul nerzhul commented Dec 18, 2018

@Calinou yes, but travis build system is very restrictive, azure pipelines is azure then more microsoft, we can upload releases from gitlab to github yes.
What is like in Gitlab is not only their pipelines which is massively good, but also their transparency and all the features you got on a repository by default :)

@ghost ghost mentioned this issue Jan 29, 2019
@ghost ghost mentioned this issue Mar 8, 2019
@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Apr 2, 2019

This is pgimeno leaving MSGitHub as announced. If I can submit MRs to GitLab, that would allow me to collaborate better than the last days I was here, so I hope this issue gets more attention in the near future.

@paramat

This comment has been minimized.

Copy link
Member

@paramat paramat commented Apr 3, 2019

I've just realised that 'ghost' isn't an actual user, took me a while ... >_>:
"Hi, I'm @ghost! I take the place of user accounts that have been deleted."

Anyway, make sure to hang around on IRC, you're an excellent contributor, i really appreciate the effort you've made.

@sofar

This comment has been minimized.

Copy link
Member

@sofar sofar commented Apr 4, 2019

Leaving a copy of what I posted in IRC earlier here:

Allowing a secondary place for PRs to happen would split the community, as some people would only see discussion posts from one side, and not the other. This isn't just unwanted, I think it would be unacceptable.

The only logical conclusion is that we can't split PR discussion across multiple places, and therefore discussion must happen in a single location only.

The result: Only the 2 following options are an improvement:

  1. self-hosted (e.g. gitlab or whatever open source variant) git
  2. mailinglist-style PR management

Both are a major change and should only be done if there is really a doubt that github is a risk. Currently I don't see this is the case, and therefore I do not believe that allowing PRs to happen elsewhere is conductive at all.

@sfan5

This comment has been minimized.

Copy link
Member

@sfan5 sfan5 commented Apr 4, 2019

Neither of those two sound like good options to take right now.
The only alternative I can think of is that:

  • a coredev opens a PR on github with the same content as a PR on another platform (kept in sync at request of the author)
  • code review and discussion with the author needs to happen on IRC
  • everything else (approvals, other discussions, pressing the merge button) can still happen on github

This approach has obvious downsides and isn't convenient, but I think it's the most viable we have.

@sofar

This comment has been minimized.

Copy link
Member

@sofar sofar commented Apr 5, 2019

I wouldn't mind seeing a patch mailinglist, so that interested devs can just git amthose and make a PR. Having to scrape 5 different collab websites isn't a good use of anyone's time, but a mailinglist is relatively easy to follow, and everyone should be able to email patches.

Then at least there's a consistent place for everyone who doesn't want github, which is better than random contributors asking random core devs to open PRs for them from random websites.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.