| Re: [rdf4j-dev] opinions on current issue tracking setup |
|
Hi Jeen,
well, I'd prefer either 1 (single tracker) or 3 (moving items to separate trackers)
Option 3 is more dev friendly and looks better for marketing purposes (less issues !),
but option 1 is easier for users (not having to guess / check where a ticket should end up) so that might be the best option.
Option two seems IMHO a bit the worst of both worlds (multiple trackers, with users and devs having to track all of them)
Just my two cents
Bart From: rdf4j-dev-bounces@xxxxxxxxxxx <rdf4j-dev-bounces@xxxxxxxxxxx> on behalf of Jeen Broekstra <jeen.broekstra@xxxxxxxxx>
Sent: Saturday, September 22, 2018 2:24:27 AM To: rdf4j developer discussions Subject: [rdf4j-dev] opinions on current issue tracking setup Hi folks,
Now that we all have some experience with the multi-repository setup for rdf4j, I'd like to take stock of how we feel about the current approach.
Overall I think the new setup is an improvement. We had a few glitches in the maven setup (mostly caused by me messing with things I shouldn't), but I think that's been ironed out now. Builds run quicker, and we have a lot more flexibility in running partial
builds etc.
A thing I personally still struggle with is issue tracking. Currently, each repo has its own issue tracker. A major advantage of this is that each repo can stand on its own as a project, and also that we can easily reference an issue in a git commit message
or PR, just by using '#<number>' or
'GH-<number>'.
However, quite often we have issues in the wrong tracker. This makes things confusing both for the submitter and whichever contributor is working on the issue.
The multiple trackers also make it harder to plan release milestones and write release notes, as we now have to create milestones in four different places, and collate issues from four separate issue trackers to write release notes - though the project
planning board helps a little in that respect.
Github has an option to refer to an issue in another repo's issue tracker on your commit messages. The pattern is
'<organisation>/<repo>#<number>.' So for example, if I make a fix in the rdf4j repository, which is related to issue #107 in rdf4j-storage, I can refer to it as follows in my commit message: 'eclipse/rdf4j-storage#107'.
However, even knowing this I make mistakes, doing a quick commit where I just use
'GH-107' instead of the full reference - which links the commit message to the wrong issue (there's an open PR right now that demonstrates this exact problem:
here). None of this is all that terrible of course, but I find it annoying, and if there's a need to revisit an issue it's problematic if the commits and PRs belonging to that issue are not correctly
linked.
So, here's where I like your opinions: should we change our setup / approach slightly? There's a couple of options I see:
From a project release/planning perspective I personally have a preference for option 1. However, I realize using such a long commit reference is a burden on day to day work.
Your thoughts, please.
Cheers,
Jeen
|