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
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
