[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rdf4j-dev] Bug-branches
|
Hi Havard,
What happened there was that I was cleaning up obsolete branches from the origin, using my local git client. I noticed an old branch named 'parent-issue-temp-branch' which hadn't been touched in a while, and neither the branch name nor any of the commits mentioned the issue number it belonged to, so I assumed it was no longer relevant and removed the branch (which led github to automatically close the associated pull request). I didn't look at the pull request (didn't realize it was there), but even if I had I might have missed that the associated issue (
https://github.com/eclipse/rdf4j/issues/2187) is still open: it's not mentioned in the PR description or in its title. In any case I have restored the branch, and though I didn't re-open the PR yet I'm happy for you to do so (though I'd appreciate it if you could rename the branch, fix the commit messsages, and fix the PR title and description).
I'd say the best strategy for branches that reproduce or demonstrate bugs like this is to use the same workflow and naming conventions we use for any other bug or feature-related branch. In the above example, we should rename the branch to GH-2187-querymodelnode-parent. As such branches are likely to be long-lived (until someone has time to actually pick up implementing the fix), we should rebase it every so often to keep it fresh against the current code base. As part of that we can clean up/clarify the commit messages if necessary. Especially because they are often long-lived, having them be descriptive and poperly associated with the issue ticket is important (otherwise people like me just forget what the branch was for :)).
If we create PRs for branches like these they should be draft PRs to make it clear that (in their current state) they are not to be merged. However, we still need to make sure that they mention the associated issue in both the PR title and the description (and preferably also link to the issue in the right-hand-side column - it makes it very easy to navigate between PR and issue and vice versa that way). Even if the code changes for demonstrating the bug are not a proper test, and not intended to ever become part of the main code base (like in this case where some println statements were added to the main code base), we can still treat these branches as the starting point of an actual fix: whoever picks up the issue can use the branch to test the code, add the fix and proper tests, and then clean up throwaway code if/where necessary so that the branch is ready for merging.
The TL;DR is: these kinds of branches don't need any sort of special treatment, we should consider them the start of an actual fix branch, and name and treat them accordingly.
Cheers,
Jeen
PS while we're on the subject of branch naming: there's still a couple of older branches by you that use the 'issues/...' convention. Not urgent but when you have time could you sort through, rename, and if necessary rebase? Just to avoid things going stale.
On Mon, Jul 6, 2020, at 19:28, Håvard Ottestad wrote:
Hi,
I’m wondering if anyone has any good experience with how to handle branches that reproduce bugs. We have a few of those in the PR queue now.
Some quick thoughts I had.
- a new “branch folder”, maybe “reproducible”
- tag the PR in GitHub
Anyone come across this issue?
Håvard
_______________________________________________
rdf4j-dev mailing list
