Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rdf4j-dev] Next patch release and new committers

As an aside, I merged the fix for #745/#778 and cherry-picked it into the release branch as well. So we now have 17 fixes lined up for this release. Full overview here:


Jeen 

On 4 May 2017, at 20:31, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:

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

On 4 May 2017, at 20:05, Håvard Ottestad <hmottestad@xxxxxxxxx> wrote:

I propose hangouts for our meeting James and Jeen. 

Håvard

On 3 May 2017, at 05:14, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:


On 3 May 2017, at 10:43, James Leigh <james.leigh@xxxxxxxxxxxx> wrote:

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. 

For some historical context, see the discussion we had about this on issue https://github.com/eclipse/rdf4j/issues/266 .

Jeen  


_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/rdf4j-dev



Back to the top