A list of old topics (and resolutions) to things covered at MouseTrap meetings

resolutions.md

Current and pending topics are available at https://gist.github.com/kevin-brown/395c9c5da3af5d8df3a0

Figure out patch workflow

Should all commits be squashed before a patch?

Squashing... if you have multiple commits, and together the represent a single conceptual change... squash. Example, you want to fix the white-space in files. First you fix the end-of-lines (those are easy). Commit. Then you fix the trailing white-space (ick). Commit. Then you convert all the tabs in indentation to spaces (finally). Commit. You should rebase and squash these into one.

If you are fixing many issues in one commit... this should probably be split out into separate commits, one for each logical change. Example. While fixing the PayPal IPN listener, you realize that the logger has a problem. So you fix it too. Commit. These should probably be split into two

-- @StoneyJackson

Should the patch body have a full explanation of what is happening?

General guidelines are at https://wiki.gnome.org/GnomeLove/SubmittingPatches

Figure out coding style

Are we going to follow PEP8?

Yes

How about PyLint?

Yes

Should a git hook be made for checking these?

In order to speed adoption and work out any bugs, we are going to try to do this using AutoTools at first. Given that it is the central tool that MouseTrap uses it, making coding style problems available while compiling will speed up the process of getting them fixed. While this can be done using a git commit hook, this would generally only be called after users have finished modifying code and serves as more of a barrier than help. In the future, a combination of an AutoTools warning and a git commit hook may prove to be the best option.

Central list of dependencies

We should probably include a requirements.txt file for any Python requirements

Throw any dependencies in the README, organized as best as possible.

Meeting Logs

Stored here, right? https://wiki.gnome.org/Projects/MouseTrap/Meetings Who is in charge of getting these online?

Brian (@paxnovem) is responsible for posting meeting notes

Any frequency or just whenever?

They should be posted ASAP after the meeting. Joanie will send them to Heidi.

Testing

Are we looking into using unittest or nose?

We are planning on using unittest until a need comes up for a different test runner.