Development Workflow (Branching Model)
ich at markusbenning.de
Tue Jan 1 14:40:24 CET 2019
On Mon, Dec 31, 2018 at 01:22:09PM +0100, Patrick Ben Koetter wrote:
> Personally I think: The simplier model is faster and it requires less
> administration. But the second model puts more emphasis on quality and I thats
> worth the price. Besides: Both models don't seem overly complicated to me.
I think more important than the question what model to choose
is to have something that is documented (CONTRIBUTING.md).
Maybe you just define it.
If you want to encourage people to submit changes and fixes I think it should
be clear what you expect and to make it as easy as possible to get
started with the project.
Its always good to use common standards and tools people already know.
I already spent some work on getting amavis in a CPAN distribution
It also splits all the class/packages from the amavisd script into
files in lib/. Another big issue is the code in BEGIN blocks everywhere.
In my option this must be changed to make the code testable (unit
I think Mark has a deep understanding of the whole project and therefor
is able to make changes and test them.
But new contributors dont have this understanding and will not know
what and how to test after making changes.
Therefor I think having automated test would be very important.
To start with tests i sugged starting with very basic unit tests
(does it compile, ...) and then add a test case everytime we extend something
or fix a bug.
I think a test suite for acceptance testing would also be very helpfull
to be able to produce something of production quality.
I would suggest using cucumber/gherkin so defining the use cases
and writing the actual test code could be seperated and split up
between different persons.
More information about the amavis-devel