Release log needs to be mapped correctly to older and newer issues

[jdrese]

mGear's uses a custom sphinx extension called changelog_links that reads the releaseLog.rst file and generates the correct links to the issues on gitHub.

[jdrese]

There are several issues...
Previous version of mGear do not contained this custom changelog_links sphinx extension in the repo. Took me quite a while to find it but finally did and it is now added and I am declaring it on the Sphinx project in a better way (that we know it is not an official Sphinx extension)...

[jdrese]

Another issue is that the current **changelog_links ** extension does not support the fact that we now have issues all over the place :D (different repositories).

What I am going to do is officially (with your approval) declare a way we put the issues on the releaseLog rst file that they get correctly mapped to the correct issue page on github.

Check the following and let me know.

For legacy purposes all issues declared as followed [#yourissuenumber] are going to be mapped to 'https://github.com/mgear-dev/mgear/issues/' as it was already the case before.

Now that I am modifying the extension all new feautres on the release log need to be added with the name of the repo in front before the # and the issue number. Here is an example

• [flex#15]
• [crank#1]
• [shifter#50]
• [shifter_classic_components#85]

That way I can map on the extension search the first part of the issue to the repo and the second to the issue and when there is none provided upfront then it is mapped to the older versions of mgear.

@mgear-dev/developers does this make sens for everyone?

[mottosso]

We've struggled with this for Pyblish too; a great idea on paper, to keep issues close to their projects, but bad idea in practice as it complicates things like these, along with search and assignments and labels and milestones and boards and backups and you name it. The same goes for the wiki.

Another option that I would recommend, having lived through the above, is that you hide the issue section on all repos but one, and use that as the one-and-only issue tracker for mgear.

That way:

1. Projects can refer to issues in commit messages using a full link, e.g. https://github.com/mgear-dev/mgear_dist/issues/19 (as opposed to just #19)
2. Issues can refer to other projects via labels, like Crank or Shifter

If you're using the "fix #some-issue" in commit messages to automatically close an issue, then GitHub is smart enough to apply those and the "was mentioned in" notification from a full link too. The issue about sphinx should be more manageable then too, I suspect.

[jdrese]

Hello @mottosso

It's funny because I was sort of thinking the same on the issues tracking (having them only on one place).

I was trying to find if that was possible on mgear-dev group itself but did not find it so maybe I can't add the issues tracking on the group (because of access rights? or simply you can't track on a group level on github) so I wanted to track everythin on mgear_dist.

I did not mention this before because I do not want to change things all over the place but if everyone agrees then I can move all issues into mgear_dist and create labels per repository and label all of those... A litte bit time consuming but worth trying.

Like I mentioned in another message I did already changed some settings on all the repositories to have them all configured the same (no projects, no wiki) but I could go and remove the issues tracking on each one of them and have this accesible only on mgear_dist and at the same time we could image that repporting an issue though mGear inside Maya could create the issue directly on github (I think this should be possible but need to check)

Anyway, let me know @mgear-dev/developers

[miquelcampos]

Hi @jdrese
Sorry for the late reply here.

I guess you already have your version, and is useless now. But, here is the changelog_links extension, I don't remember where I have found it. But This is a modification I did to work with issues in separated repositories
changelog_links.zip

So with this, you can set the repo and number issue like this

[crank#1]

[jdrese]

Thanks @miquelcampos
I was lucky and found (the same extension) as well but that constains some more interesting filters in it but I can combine them. That been said I will change it in order to have it reading mgear/issues and mgear_dist