[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rdf4j-dev] opinions on current issue tracking setup

I've migrated all our open issues and have asked the Eclipse webmaster to close the issue trackers on our other repos. I've also added a couple of new labels to identify issues that affect one of the other repos.

Signing off for the night, I'll try and fix the PR templates tomorrow.

Cheers,

Jeen

On Wed, Oct 3, 2018 at 8:04 PM Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:
I've found a useful online tool that can assist with moving issues: https://github-issue-mover.appspot.com/ . I've tested it on issue https://github.com/eclipse/rdf4j-doc/issues/60, which has been moved to https://github.com/eclipse/rdf4j/issues/1091. Unfortunately it doesn't preserve the original author (that's not technically possible with the Github API), but it adds references and makes it clear what happened.

I'll start migrating issues over in earnest after the 2.4 release is out the door.

Jeen

On Wed, Oct 3, 2018 at 9:09 AM Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:
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.

Jeen

On 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Ãvard

On 2 Oct 2018, at 13:34, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:

So, 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,

Jeen


On 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,

Jeen

On Mon, Sep 24, 2018 at 5:39 PM HÃvard Ottestad <hmottestad@xxxxxxxxx> wrote:
Hi

How 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Ãvard

On 22 Sep 2018, at 13:48, Bart Hanssens (BOSA) <bart.hanssens@xxxxxxxxxxxx> wrote:

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:
  1. 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)
  2. 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
  3. 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