Missing discipline with checkins

David Nolden zwabel at googlemail.com
Tue Jul 22 02:04:33 UTC 2008


Am Montag, 21. Juli 2008 20:35:29 schrieb Andreas Pakulat:
> I'd like to ask for some more discipline with checkins. Right now trunk
> doesn't build because the duchain tests are not building. I've also had\
> to fix a couple of extra ";" that occured after macro's to even get
> platform compiled. Note that dirk's dashboard compiles with -pedantic
> on, so we'll be red as long as those are around.
Yeah time to enable that -pedantic flag again, it probably got lost somewhere 
while creating new build-environments.

> Basically one should obey the basic SVN guidelines for KDE's svn
> repository, written down here:
> http://techbase.kde.org/Policies/SVN_Commit_Policy
>
> Especially the first four points. That means everybody who wants to hack
> on KDevelop needs to
>
> - enable building of tests via -DKDE4_BUILD_TESTS
> - rebuild both kdevplatform and kdevelop - completely! before any
>   checkin
I understand the problem, but the first is currently not an option. Already 
now, I spend a significant part of my development time waiting for the 
compiler to finish, and I don't want to increase it even more, becoming even 
less productive. Unfortunately I have to work on core parts atm that usually 
really trigger a lot of rebuilding.

In the last case I forgot that cmake has duchain tests too, I'm sorry for 
that.

> I don't think thats too much to ask, given that some of us have really
> limited time and would like something that at least compiles.
I understand that. I'll try being a bit more careful when committing.

> And for next years SoC if there will be one, I think we need to have
> feature branches for the SoC projects - especially if the projects work
> on core parts.

I'm not sure of that. You would just postpone problems to a later point, when 
you have to merge everything, and all in all you have even more problems. 
People would be writing code for obsolete APIs, creating even more code that 
needs to be ported later. Me and Hamish would have done tons of completely 
incompatible changes during this SOC, if I had used a branch. Above that, 
people want to see the whole progress, without having to compile another 
version of kdevelop for each development branch. Also branching with SVN is 
not fun, with git it would be something different.

Branching does make sense where something is completely rewritten, and where 
it's clear that the new code is less functional/much less stable then the 
previous code. For other cases, it would be better having a "stable" branch 
for using, and a "trunk" branch where most of the development happens. I 
seriously think we should switch to git in near future..

Greetings, David




More information about the KDevelop-devel mailing list