Thoughts about a better Quality Management process for Plasma

[Aaron J. Seigo]

On Monday, January 14, 2013 17:22:14 Martin Gräßlin wrote:
> On Monday 14 January 2013 16:24:28 Aaron J. Seigo wrote:
> > a merge commit can document exactly what it is merging, feature or bug
> > fix,
> > and that can also be used to generate a changelog.
> 
> that's a good point. Sounds like a reasonable alternative. What I actually
> wanted is to have documentation about what is going on.

me too; i tried with getting people to put FEATURE in their commits, and 
tracking based on BUG: etc notes in commits ... but it just isn't overly 
reliable.

the one thing i like about merge based tracking is that if merges are required 
to get features and fixes in, then it becomes self-documenting.

any time we can stop relying on people (ourselves, even :) to be highly 
disciplined and let the computer do it instead, i prefer that approach.

> > for the non-GUI bits, i agree. one wrinkle in this, however, is that much
> > of this code is async, and this is only going to be more and more the
> > case in future. so if this is going to be a goal, then we probably need
> > to invest some time into making it dreadfully simple to write tests that
> > require the event loop and waiting for responses.
> 
> sounds like something we could spend an GSoC on. "Testframework for data
> engines" - something like that.

+1

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130115/5dab9172/attachment.sig>