This could possibly help in two ways - I know that a lot of developers prefer to hack features, where TDD is not always taken into consideration.
We could _ask_ that developers take a TDD approach and open a new contributor role to look at any old/new code, refactoring it into a TDD fashion and adding new tests where they are missing? Cheers, Kenny. p.s. Apologies if this double-post :/ On 7 April 2012 20:13, Frank Karlitschek <[email protected]> wrote: > I think it a great idea to do continuos integration. It´s a good thing to > ensure quality. > I just wouldn´t introduce too much processes and bureaucracy so that´s > still easy and fun to contribute for new people. > > And we need an volunteer to set everything up of course :-) > > Frank > > > On 06.04.2012, at 13:42, Jörn Friedrich Dreyer <[email protected]> wrote: > > > Am 06.04.2012 13:08 schrieb "Michiel de Jong" <[email protected]>: > > > but you just configure git to only accept merges whose tests pass. > > > that way it's the responsibility of the person committing new code to > > > not create any regressions on existing functionality. in case of > > > conflict, the already existing master should be kept, not the new > > > commit. > > If we start adding continuous integration I highly recommend gerrit to > manage branches and commits. We can start by letting gerrit automatically > push changes that pass the testsuite into master. Should we need a more in > depth review we can later add the voting process. > > > > So long > > > > Jörn > > _______________________________________________ > Owncloud mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/owncloud >
_______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
