| Re: [rdf4j-dev] opinions on current issue tracking setup |
Yeah, that's exactly the idea. When I say a single tracker, I mean that we will use the github issue tracker at eclipse/rdf4j for all issues.If we do this I'll migrate existing issues in the other trackers, and then ask the eclipse webmaster to disable those trackers.JeenOn Wed, Oct 3, 2018 at 2:15 AM Håvard Ottestad <hmottestad@xxxxxxxxx> wrote:Could we do a single tracker in our main repo?_______________________________________________Not a big fan of having yet another system you need to log into. Especially for external users who just want to post a bug.HåvardSo, summing up, we have 2 preferences (myself, Bart) for option 1 (single tracker) and 2 preferences (Bart, Havard) for option 3. Anyone else want to weigh in on this? Havard, you have any strong objections to option 1?As an aside: referring to an issue in a different repo is more complicated than just doing #<number>, but if there's only one tracker we can just adapt the PR templates to include the standard pattern eclipse/rdf4j# . As a PR submitter you'd still only have to type in the issue number.Cheers,JeenOn Mon, Sep 24, 2018 at 7:50 PM Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:I'm not really keen to migrate the code base to one repo again. It's a massive amount of work, not only the code migration itself but also getting all the Jenkins stuff set up correctly to handle the build and the deployments to Sonatype. We just got it (more or less) right.As for moving issues, I'd be fine with that option, but there is one practical problem: Github has no option to move issues from one repo to another. So moving issues in reality means creating a new issue on the target repo, copying over the issue description, adding a reference back to the original, and then closing the original. It's a bit of a pain, but it's doable, and if we decide this is the easiest option I'm ok with it.Cheers,JeenOn Mon, Sep 24, 2018 at 5:39 PM Håvard Ottestad <hmottestad@xxxxxxxxx> wrote:_______________________________________________HiHow about one repo, with 3 directories. One directory per repo we have today. No root pom.Other than that I reckon that “moving” issues is the best option.HåvardHi 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 setupHi 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:
- we switch to a single issue tracker, and everybody makes sure they use the correct commit reference (or at the very least in the PR)
- we keep multiple issue trackers, and if an issue is in "the wrong tracker" (or affects multiple repos) we just deal with that by using a correct commit reference
- we keep multiple issue trackers, and if an issue is in "the wrong tracker" (or affects multiple repos) we move or copy the issue.
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
_______________________________________________
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
_______________________________________________
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