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

List:       kde-panel-devel
Subject:    Re: Re: Thoughts about a better Quality Management process for Plasma
From:       Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= <mgraesslin () kde ! org>
Date:       2013-01-14 16:22:14
Message-ID: 3047295.piBZGsWOQn () martin-desktop
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

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

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


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