-----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) - - ...? Why would you use Django to build the tool as opposed to "just" a python package? 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
