Contributor PR workflow

[lukego]

Howdy! I am a first-time contributor with PR #9 and I have some questions:

• Who is responsible for deciding when to merge my code?
• What are this person's requirements?
• What actions do I need to take to satisfy them?

[dibyendumajumdar]

hi you could just ask for commit access.

[lukego]

True. However as a contributor I am hoping to use the Fork and Pull model and this requires a maintainer to engage with me after I open a pull request and make sure the changes are moving the repo in the right direction. Is someone(s) taking that role on this repo?

[Wiladams]

Several people have that ability. Just do your thing and it will get handled. The main problem we faced early on was over protective handling of the repo, and thus nothing has happened. Make your changes, and make your pull request.

[Wiladams]

And keep in mind, Mike said in the beginning, all history will likely be lost once this test report is merged into something else, like the main LuaJIT repo. So, branching, and pull requests and the like are more of a personal style and cleanliness/safety thing than a strict requirement.

[lukego]

@Wiladams Groovy. So here is how I see myself cooperating with other testniks:

• I maintain the branch lukego/luajit-test-cleanup#branchmarks. This is a public branch with a stable history that is safe to pull from. I have made this a protected branch on Github to avoid even accidental force pushes.
• The purpose of the branchmarks branch is to provide the test suite for CI. My job as maintainer is to pull improvements to the test suite but make sure they are compatible with the CI before I push them. The invariant is that branchmarks always runs the code that is live on CI.
• I would like to have one or more branches to pull improvements from e.g. the master branch on this repo. However I would need to know that these branches will never be force pushed (see link above about public branches). So it would help me if there were a known policy on whether the master branch here has a stable history (e.g. perhaps you guys could consider making it a protected branch too).
• I will probably make my test suite changes on topic branches and PR them here for discussion. You guys could decide whether to review/merge/reject them individually (separately for each topic branch) or collectively (pull the whole branchmarks branch).

How does that sound?

[lukego]

(and yes I understand that we may need to completely replace the workflow in the future e.g. if this code is all moved into the luajit repo, etc, but we can deal with that when it happens.)

[nico-abram]

What's the current state of this repo?