On Tuesday 19 May 2009 04:18:57 Harald Welte wrote:
Dear Andreas,
first of all, as I indicated in the past, I am very thankful for the amount
of work you are committning to OpenBSC. So please always keep this in
mind!
Dear Holger,
we all bring different skills to this project. Andreas' strength is that
he has a lot of knowledge of traditional ITU-T/ETSI telephony protocols,
something that we clearly don't have. Apart from all his work, he actually
also documented his work in detail - even if in a method quite uncommonly
seen in FOSS projects for development discussion (colorful HTML on his
website).
You on the other hand (like me) have extensive experience in participating
in large FOSS projects that follow certain rules and 'best practise' when
it comes to the structure of contributions.
Andreas is trying to help us with his code, so please be friendly and
welcoming to him. I agree with you that the mode of submitting one large
patch rather than an incremental per-feature patchset is not how
contributions are normally acceptd. I also agree that cosmetic/syntax
changes need to be kept separate from actual semantic changes of the code,
or that autotools should be used the "right" way - but we can communicate
that in a nicer way.
Dear Andreas,
sorry about the tone. I'm very interested in getting your changes into the
OpenBSC repository as they are great improvements. My mail was not meant to be
rough but was meant as a way forward to get things merged before you end up
with a huge pile of changes (this was probably the reason that harald and me
started to merge bits and pieces by hand as well). I sincerely agree with
Haralds proposed order of changes and please let us progress this way.
z.
PS: Sorry, I went to bed early here, I try to reach you tonight
Some more bla bla on why small chunks of changes.
First of all we have all limits, by having smaller changes we are better to
judge this individual change, the impact and such without reaching the limit.
Having small independent changes allows us to roll-out (revert) a particular
change (e.g. when our judgment was wrong) without ending in a big manual merge
catastrophe. And finally by having each change compilable we can fall back to
things like git bisect.