Filing Matrix Bugs

Is github now the appropriate place to file grammar matrix bugs? Have we officially transitioned?

1 Like

Good question, Kristen. But first, for those not following on the matrix-dev mailing list, let’s summarize what’s happened.


I began transitioning the Matrix to Python 3 since Python 2 is retired. So far I’ve got it so the regression tests would pass, but I have not tested the questionnaire or other parts, so there may be still some work to do there. Furthermore, this process is revealing architectural improvements and other maintenance that the Matrix is due for, so I’ve begun some of that work in separate branches.

Separate from, but for the benefit of, this work, I have imported the Matrix’s SVN history into a Git repository. Most Matrix developers who voiced an opinion seemed to prefer hosting the repository at GitHub instead of the GitLab instance of UW’s linguistics department, and Emily agreed. During the transition I had the repository first as a private repo under my account and now it is public: I have also imported the existing Trac tickets to GitHub issues. The plan is to move it under the delph-in organization on GitHub once it is all working.

Finally, I had originally planned that the current SVN-to-Git and Trac-to-GitHub imports would be test runs and that I would resolve any issues with the process from feedback received from Matrix developers and re-run the imports for the final version, but it went fairly well the first time and I didn’t get much feedback about things that needed to be changed. Since work has progressed with the current setup, I’m feeling less excited about re-running the import and then recreating the subsequent changes.

I’m generating a long list of things that could be improved. Much of this is in my head, but I’ve put some things down on this kanban-style project board: Some things have been discussed on the matrix-dev list (and thanks to all who’ve participated).

Back to the question…

You can file issues on the old Trac system and I can import them later, but, assuming I don’t have to recreate the GitHub repository, it would be better if you file them on GitHub (less work for me, but also new issues will be properly associated with their creator and not just me). Similarly, you can still commit to the SVN repository, but I’ll need to import those commits later, so it would be great if you could fork the GitHub repository and work there.

Another question…

@ebender, maybe I should move the repository to the delph-in organization now? I would still like someone to test if the questionnaire works (I don’t recall the password to install to UW’s server, and it’s not trivial to run it locally), but I don’t want confusion about where development should happen.


I actually don’t think that will switch to the new version just yet… I want to defend first (and switching versions will undoubtedly set me back a few weeks). I think I want to defend first and then convert my library to python3 and merge later. I know it is not ideal but I think that’s probably best.

1 Like

That is totally reasonable and doable. I think we can still shift development on the main branch (formerly “trunk”, now “master”) to GitHub while you continue on your branch in SVN, then convert and merge later.

So what did we decide about filing current bugs? Where do they go, the new place?

Not very relevant for this thread, but I didn’t find the link for subscribing to the matrix-dev mailing list in the GitHub nor in the matrix wiki page.

Please file them on GitHub. Emily gave me the ok to move the repository to the delph-in organization, so please go here:

Also note that Emily agreed that we should rename the “master” branch to “trunk”, so if you have already cloned the Git repository you can either clone afresh or do:

git pull
git checkout trunk

If you have already made commits to the master branch in your clone, let me know and I can help you rebase them onto the trunk branch. Otherwise you can get rid of the old master branch:

git branch -d master

There are still references on the wiki to the now defunct “matrix” list, which was intended for users and has since merged with the “developers” list. The matrix-dev list is mainly for UW students who are actively working on the Matrix source code and not for users of the Matrix. Except for the discussions from last month and for automatic notifications about commits to the (old) SVN repository or Trac issue tracker, the matrix-dev list is very quiet. If you wish to get involved with Matrix development, I suggest following the GitHub repository. If you have issues as a user, I suggest the developers list or this message board.

1 Like