Thoughts about a better Quality Management process for Plasma

[Martin Gräßlin]

On Monday 14 January 2013 16:24:28 Aaron J. Seigo wrote:
> > *Every commit should be referenced to a bug*
> > What is the motivation for a commit? It's either a bug fix or it is a new
> > feature/improvement. If it's a bug it's clear that there has to be a bug
> > report for it (out of experience: there is always a bug, if not: create
> > it). If it's a feature, it should also have a feature request in the
> > tracker. Create it yourself if you need to. Sounds beaurocratic, but it
> > comes quite handy as it allows to generate changelogs from it, allows
> > people to easily test new features.
> 
> a few challenges to this:
> 
> * many features, and even some bug fixes, are large enough to warrant
> multiple commits. yes, we can CCBUG every single commit, but that seems
> really overkill (and is going to make my inbox bulge ;).
as written in another mail: I only meant once per branch
> 
> * it means adopting bugzilla as our One True Workflow tool. that doesn't
> just sound beaurocratic, it is beaurocratic. if someone appears with a
> patch fixing some bug or implementing some feature that isn't in bugzilla,
> do we first send them to create one before accepting it? ugh.
no rule without exception :-) (note: in everything I went for the absolute 
extreme, where I do not actually want the extreme)
> 
> i think one of the main motivations behind this style of development is the
> practice of doing development in a shared branch (e.g. master).
> 
> if development instead is done in separate topical branches, the branches
> become the documentation. it also works with the regular development
> workflow without causing trips to bugzilla (or redmine, or whatever tool).
> 
> 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.
> 
> > *Bug fixes should come with a unit test*
> > Plasma so far does not have any unit tests.
> 
> only in kde-workspace. libplasma does indeed have some ... but certainly
> nowhere near a majority of code paths covered.
I meant inside the workspaces - sorry if that caused confustion
> 
> > Why? Let's not fool ourself with
> > "it's UI, that's difficult to test". No it's not, because Plasma has a
> > great separation between UI and logic. It would not be a problem to create
> > a unit test for the data engines.
> 
> 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.
> 
> --
> 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/20130114/c4451e7f/attachment.sig>