Assuring Quality and Bug Fix speed in Open Source Python Project

Question

I'm maintaining an open source framework (in Python on *nix platforms if that matters) for the first time in my life. It is pretty much pre-alpha, not much more then a scientific proof of concept, yet. But it is also already used in production by another department because it is the only framework globally that approaches their needs. Now there are two anti polar goals: quality and development speed.

Of course I want quality in form of documentation, unit tests, code reviews and some kind of "beta" usage, before I am confident to let a change be used in production. But the development team has dead lines and when they find a bug, which happens rather often in this prototype, then they need the bug fix to be in production very fast. I have currently no working solutions and our ideas diverge.

I think this project can't be the only one with that problem. How do other projects solve this?

I'm going to post my idea and the dev teams idea as answers for further discussions, both ways are not a solution though, because my idea basically only focusses on quality and their solution only focusses on speed.

Answer 1

You might find that at the beginning, if there are a lot of bugs needing fixes, then something like the dev team's preference is more appropriate. Once the code is a little more stable, then you can shift more to what you have in mind.

Answer 2

My solution:

There are two branches:

• master contains only stable, tested builds
• dev contains the most bleeding edge development state
• f-<xyz> feature branches, which contain features and bug fixes that are currently under development and not acknowledged for the dev branch yet; that's possible because most people working on the project have writing permission to the repository, which is company rule

Each feature request or bug should go through the following process:

1. Write an Issue on the project page, which contains the problem description, the suggested solution and further notes like the feature branch name.
2. Check in and Push your changes to the feature branch and reference the Issue.
3. Find 2 people to review and acknowledge your change (looking for mistakes, unclear text, that the documentation is up to date and that there are unit tests for the change)
4. After getting 2 ACKs find a maintainer to merge your change into the dev branch.

This process depends on at least 2 other people (if one of them is a maintainer) and even afterwards it is not released yet, it's just in the dev branch.

For a release to happen: 1. Someone needs to prepare the release * find a meaningful release candidate commit * check again for stability, quality and documentation * mark the release candidate * get the okay at a weekly project meeting through votes

All users should use the last release or must be able to adapt their code to structural changes and unexpected bugs themselves, if they are using the dev branch directly.

As said in the question this mostly concerns about quality and longevity of the project, which is my main goal. The development team in a production environment of course needs speed as well.

Answer 3

Dev Team's solution:

Just one branch is needed: master. Everybody can push to that branch and reviews aren't necessary. Every body is responsible that this branch's HEAD is working correctly and is not breaking the projects that rely on it. Solutions should be added when needed and quality assurance as documentation and unit tests can be added later on.

I don't think in this approach there is anything that will keep quality alive. The production team will never have the time to write documentation and unit tests and nobody will review the code.