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
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
