| Works for me. Can you start one at the right time and send us the link?
In case you can’t reach me on Hangouts, I’m also lurking on IRC: #rdf4j on freenode.
Jeen
I propose hangouts for our meeting James and Jeen.
Håvard
Thursday 12Z is good with me. The release branch looks good to me as
well.
Great! I’ll pencil it in.
In other projects I have worked one we adopted the practise of using two
active branches (one for patch releases and the other for new features).
When a PR is created it is targeted to one of these two branches
depending on whether it is a bug fix or a new feature. This way both
branches are always in a release ready state (patch release ready and
minor release ready). I have documented how RDF4J could adopt this
process here[1]. The major difference is that every PR is scheduled for
release before it is merged.
We actually did that previously as well, but the problem is that we get many Pull Requests by non-committer contributors who don’t know what branch to target their PR against and/or start off their fix from the wrong source branch.
Github doesn’t allow you to change the target branch for a PR, so we’d end up having to ask the submitter to close the PR and create a new one for the correct branch. And if they used the wrong source branch for their fix it’s even harder to get things to align, they'd have to rebase. In short: painful.
The current workflow is adopted with the idea to make it easy for occasional contributors: they can just always use the master branch. Indirectly that also makes it easier for us as lead committers: it creates a bit more work when release time looms, but it saves us having to explain these things to contributors every time and wait for them to fix their PRs.
Jeen
_______________________________________________ rdf4j-dev mailing list rdf4j-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/rdf4j-dev
|
