Missing discipline with checkins

[Andreas Pakulat]

On 22.07.08 04:04:33, David Nolden wrote:
> 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.

Well the pedantic errors usually limit themselves to extra ;, which is
easily resolved without me knowing anything about the code. More severe
are missing ports of parts of the codebase.

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

I'm with Matt here, if you want to work on a code-base that has
unit-tests you _have to_ build them at least - even if just once before
comitting your changes so you know you don't break other people's code.
You're violating an important rule of KDE's svn commit policy here.

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

So you think its ok that your peers waste their time?

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

With enabled tests you wouldn't need to remember that, the buildsystem
would tell you. 

I urge you to think about better ways of speeding up your builds, use
ccache (yes I've been bitten by it once or twice, in general though its
working great and its speeding up things a lot) and use the latest CMake
so re-linking/installing gets a lot faster.

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

Apparently it works for other projects quite well.

> You would just postpone problems to a later point, when you have to
> merge everything, and all in all you have even more problems. 

But one would avoid the breakages in between the points where the code
works. I wasn't thinking of creating a branch at the beginning of SoC
and then merging when SoC ended. That indeed might prove a bad idea.
However working inside a branch between the major milestones and thus
breaking the working version once for maybe a day or three and then not
again for 2-4 weeks. 

> People would be writing code for obsolete APIs, creating even more code that 
> needs to be ported later.

Yes, but it would need porting only once. With all those intermittent
code/API changes you're doing the porting again and again and again.

> Me and Hamish would have done tons of completely incompatible changes
> during this SOC, if I had used a branch.

Well, obviously you would have both had to work on the branch.

> Above that, people want to see the whole progress, without having to
> compile another version of kdevelop for each development branch.

Uhm, kdevplatform -yes. But not kdevelop. Everytime I did some major
changes in a plugin in Kdevelop I've only branched that plugin, made it
compile standalone and then work on it. In fact the QMake plugin can be
branched in about 5 minutes because it now only needs two find_package()
calls added at the top of its CMakeLists.txt.

> Also branching with SVN is not fun, with git it would be something
> different.

Thats the only argument I agree with. Though I hope to be able to play
with svn 1.5 sooner or later and if it really helps the
branching-problem we may just need to talk sysadmins in upgrading to svn
1.5 on KDE's server.

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

Thats unfortunately not an option this year (lacking a stable version of
kdevelop4) and is going to be even more problematic next year - unless
we drop the idea of following the KDE release cycle. Because as far as I
can see the 6-month rythm works quite well for them, which means a
release is in the middle of SoC and thus you'd have to start your work
in a branch anyway.

> I seriously think we should switch to git in near future..

Or some other VCS system that allows for easier branching. But that
belongs into its own thread, wanna start that discussion?

Andreas

-- 
Beware of a tall black man with one blond shoe.