Thanks Florian for these suggestions, i have added some more details that i think need to be discussed.

On Mon, Mar 3, 2014 at 3:01 PM, Florian Fuchs flo.fuchs@gmail.com wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 02/22/2014 07:54 AM, Varun Sharma wrote:

...

Hi all, I am interested in continuous integration tool as my gsoc project and would like to discuss further it's possible implementations. I think one possible implementation for gatekeeper is :

Making another django project mm_gatekeeper which every developer must run in order to commit to trunk. We can host its repo of on launchpad. It will act as a proxy to bzr and will perform bzr commit only after all the unit and doc tests succeeds.

bzr pull can be implemented as

$ mm_gatekeeper PROJECT_NAME pull

or to pull all projects

$ mm_gatekeeper pull

Instead of using bzr commit in postorius we can use

$ mm_gatekeepar PROJECT_NAME COMMAND

$ mm_gatekeeper postorius commit -m"commit message"

I like the idea of having a command line tool to run integration tests! It could be used both by the devs working on the different packages as well as on a central ci server that runs those tests regularly. But I'm not sure it should be tied that closely into the commit/merge process:

When a developer works on a new feature in a branch separate from the main line, it's probably very common to commit small changes that would break the whole system, but are commit-worthy anyway because they sum up a small series of changes in a chain of more commits that eventually lead to a mergeable state.

So when I (as a developer) *think* my stuff is ready to be merged into trunk, *that's* when I would like to check if everything's fine and run the integration testing tool.

Another thought: What versions of the various Mailman packages should the ci tool test against? Should that be configurable for different test scenarios? Like:

• • Use the branch I'm currently working on, but get all other packages

from their respective main lines (the perspective of a developer working on a new feature before merging).

• • Use the current main line of one package, but everything else from

pypi (the perspective of a developer when preparing the release of one package)

• • ...?

I think we can include a list of branches/versions to be fetched for testing of integration in settings for every project . I also wanted to discuss, whether it's a good idea to test the code on the developers machine before committing or we should just go by the buildbot implementation(running builds on different servers after getting a commit on repository).

If we run tests on developer's machine: Pros:

1. The possible integration error can be detected early, and can prevent

committing the erroneous code. Cons:

1. All the developers of different projects will be required to pull the

code of all the projects involved in the suite. 2. Running unit tests may take more time on developers machine than on slave server.

If we run tests after getting commit on trunk: Pros:

1. We can set different slave servers with different operating systems just

like buildbot and the tests will be more reliable. 2. Time of developer in running the tests for all the projects can be saved. Cons:

1. The erroneous code in the trunk may get exposed to the end users before

getting fixed by the developer.

So I think we should have a mix of these two :)

Why would you use Django to build the tool as opposed to "just" a python package?

I was thinking of expanding it like buildbot to include django based GUI and detailed reports. So i thought we can use django, but if we just want a command line tool, then python module will be fine.

Cheers, Florian

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFEvWAAoJEEceGbPdavl7UPMH/A5cd7PWdw+qMaOFRfxfTVuV lvwdwTOb/Z7oeeE5bol/czvuG7ejaBi5fVxerSb2Ffo4N8aESP1gmxt4U+Qp1SFr 0oIORix0L35Kz19MurbODaZzphjZB5Hf/F/Fu0OgbS4KmDf1nnMvVvXusB6vOxM4 lvg/AOb1GyGuYd78Cj4GA2CY6oCfh2pAjmzUKI4ULvzHjGFHYtjanmYgaB+cjdwB mNaZbJtQKcjBTvl6iXAON0MU2SzmMG9psA/LcR2hRQMZncBxe0Lbh3fEAA7IHuKe rzqT2lyX3cBZtvsH06TlLwYmxyJp8Z3HTv6Txj7y+YvvrL4Sj5c6fYTts7OtE1M= =fci5 -----END PGP SIGNATURE----- _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/varunsharmalive%4...

Security Policy: http://wiki.list.org/x/QIA9

Thanks Varun