[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Thoughts from a former KDE, currently Mozilla developer
From:       Kevin Ottens <ervin () kde ! org>
Date:       2010-12-08 14:22:19
Message-ID: 201012081522.25099.ervin () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 8 December 2010 15:09:38 David Jarvie wrote:
> On Wed, December 8, 2010 8:38 am, Kevin Ottens wrote:
> > On Wednesday 8 December 2010 02:51:46 Aaron J. Seigo wrote:
> >> On Tuesday, December 7, 2010, Benoit Jacob wrote:
> >> > *****
> >> > 3. QA, Unit-testing, continuous testing (KDE: very little, Mozilla: a
> >> > lot)
> >> > 
> >> > Let's face it, KDE has always been deficient in the QA department. In
> >> > 
> >> > order to ensure good QA, it needs:
> >> >  * a lot more unit tests than it currently has
> >> 
> >> agreed. care to donate some resources? :)
> >> 
> >> >  * unit tests must be automatically run, frequently.
> >> 
> >> agreed; people are working on automated unit test set ups for kde. we
> >> have
> >> 
> >> more variance than mozilla does however, which means this:
> >> >  In mozilla,
> >> > 
> >> > everything is built and the unit tests run on 10 configs everytime you
> >> > push to the repository, see http://tbpl.mozilla.org/
> >> 
> >> would be great. given our resources and the variety of our targets,
> >> highly unlikely for now. in future, perhaps.
> >> 
> >> >  * regressions must never be tolerated. if a commit causes a
> >> > 
> >> > regression, back it out.
> >> 
> >> ah, blanket statements. as a rule of thumb: good idea. rigidly followed:
> >> stupid, as it's an awesome way to discourage development contribution.
> > 
> > Note that it piggy back to unit tests IMO. If a commit causes a
> > regression caught by a unit test it should be reverted indeed. If that
> > happens it's mainly a problem during the reviewing phase and so on.
> > Going beyond than that
> > could indeed discourage development contribution (unit tests are easy
> > enough to run before you send the patch to be a good compromise).
> 
> For smaller commits, it seems reasonable to demand that they don't cause
> regressions. For larger commits, it won't always be possible to test
> sufficiently for regressions before committing - there may be too many
> affected apps if a change is made in the libraries, and a single developer
> can't be expected to have the time or knowledge to test multiple apps.
> [...]

I didn't claim that. My point is that at least the unit tests shouldn't show 
any regressions, I never talked about getting to each application and test it 
manually.

Really, running the automated tests before submitting is a low enough price to 
pay, but would improve the quality quite a bit.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]