patches for openbsc

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Holger Freyther zecke at selfish.org
Tue May 19 05:01:56 UTC 2009


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.


  




More information about the OpenBSC mailing list