Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 7:07 PM, Bradley Giesbrecht <pixilla at macports.org> wrote:
> 
>> On Oct 7, 2016, at 4:02 PM, Rainer Müller <raimue at macports.org> wrote:
>> 
>> On 2016-10-07 20:58, Christopher Jones wrote:
>>> 
>>>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez <larryv at macports.org>
>>>> wrote:
>>>> 
>>>>> On Oct 7, 2016, at 2:09 PM, Chris Jones
>>>>> <jonesc at hep.phy.cam.ac.uk> wrote:
>>>>> 
>>>>> Currently, once they find out about svn, and trac
>>>> 
>>>> We will still use Trac for issue tracking, although I believe
>>>> someone is looking into integrating GitHub sign in.
>> 
>> Trac will stay. Clemens and I already wrote new modules for the
>> trac-github plugin [1] in order to allow both login with GitHub as main
>> authentication provider, migrating old tickets from mail addresses to
>> the GitHub accounts and all permissions in Trac will be based on team
>> memberships on GitHub.
>> 
>> The only downside is that references to tickets will have to become full
>> URLs to Trac, because GitHub claims the #12345 syntax for their own
>> issue tracker and pull requests. Commits which contain such an URL will
>> automatically be linked from the corresponding ticket.
> 
> See comment below, we use #12345 syntax in with our Redmine issue tracker.

The problem is that when you write "#12345" in a git commit message, the GitHub repository browser web interface will link that to GitHub issue or pull request #12345; you cannot prevent that. Therefore, we must not use that syntax, except when we really mean to refer to a GitHub pull request, and must instead use the full Trac URL to tickets when we are referring to Trac tickets.


>>> Personally I think we have to migrate away from trac as well. Pull
>>> requests in GitHub will largely replace what happens in trac for
>>> submission of patches and the discussion of them. If we stick with
>>> trac for issues then for me it will be an utter mess.
>> 
>> Pull requests can be used in addition to tickets. For simple port
>> updates, there will be no need to open a ticket.
>> 
>> We evaluated several options, including issue trackers provided by
>> GitHub, GitLab, BitBucket, JIRA, and also others and finally came to the
>> conclusion that Trac is still the best option at hand.
>> 
>> Especially with hosting our own installation, we will finally be able to
>> make more modifications and use custom plugins, that we never got
>> deployed at Mac OS Forge (for example [2]).
> 
> 
> Redmine is outstanding in my opinion.
> 
> There is a Redmine github plugin [1] allowing Redmine installation to receive Github post-receive notifications.

> [1] https://github.com/koppen/redmine_github_hook

Just as there is a trac-github plugin which we're going to use.


> Redmine parses commit messages for configurable strings and can change issue status and add commit references to issue.

Rainer and Clemens are working on doing that for our new Trac install as well.


> Redmine can work with Subversion, Darcs, Mercurial, Bazaar, Git, and others.

Trac works with Git and Subversion; I don't know if it works with others but I don't care because we don't use others.


> Oh, and Redmine is a quick and easy rails install away.

I assume Trac wasn't hard to install, but in any case, we've got it installed already.


We are staying with Trac for now; evaluations of other systems and discussions of their respective merits have concluded. Staying with Trac is the easiest option, given all the other work we still have to do to convert to GitHub. We can always revisit it later, should the capabilities of other systems change for the better.