How to contribute to Buildout
What is slapos.buildout
slapos.buildout is a fork of zc.buildout (http://buildout.org) maintained by the SlapOS team
that includes all fixes made by the team.
Ideally, all fixes should be merged to zc.buildout upstream repository
and code should be kept synchronized.
How to enhance zc.buildout / slapos.buildout :
- If not already done, create a new bug in zc.buildout bug tracker
- Fork https://lab.nexedi.com/nexedi/slapos.buildout
on gitlab.
- Create new branch, from master branch. Name of branch must be id of bug in github.
- Write your changes.
- Test your changes (see below)
- When branch seems stable, make a merge request on Nexedi gitlab and ask for review.
- If reviewers agree, they will merge and ask new release of slapos.
Some rules to follow to make maintainer happy
- Don't commit anything to master, but commit in dedicated branch!
How to test zc.buildout
To develop zc.buildout correctly, please follow strictly: https://github.com/buildout/buildout/blob/master/DEVELOPERS.txt
Quote from maintainer
I was running whole buildout test suite. First on upstream clean branch
in order to see results on my current box. Then I was running on branch
and I compared the results. There are some errors and failures on clean
upstream codebase with python2.7, it is responsibility of releaser to analyse it and
ignore them or not (e.g tests related to existence of some specific binary in
/usr/bin/ are not important).
So I extensively used git and buildout developers hints (they are
availalble in slapos.buildout repository) in order to release buildout
versions. Sometimes I made mistakes (again I refer to log of
slapos.buildout), but well...then I re-released.