development process (was Re: 7bit changes to libosmocore)

Dear Holger, I think you have iterated the point about 'wasted time' sufficiently enough. I understand you being upset, and the point has been driven home to everyone very clearly. I take responsibility for merging the 7bit changes. The 'make check' was unfortunately only discovered immediately after the push, and I sent a notice to Andreas that this needs fixing. The discussion of 'stability' vs. 'merging new developments' is a difficult one, and each project has to find its way around that. Linux had parallell stable an development trees for a long time, but this requires a lot more additional effort and people who actually work on 'stable' with time and discipline (and a motivation to do so, which often results from commercial use). I would personally satte: 1) there is no excuse for not running 'make check' to apply existing test cases against changes that are proposed for merging. No exception here. 2) patches requested to be merged should generally be sent through the applicable mailing list before merging them to master. No merge requests via private e-mail, and not just by mentioning a branch but by posting the entire patch set, patch for patch (git-send-email). This gives them much more visibility to more people. 2) for 'master' I would still want to see a more relaxed attitude than only accepting changes for which comprehensive test cases exist. That is too extreme. We need to balance stability vs. innovation here. Master may break things here and there. It's not a release for production use. 3) We should discuss whether we actually would like to start making formall releases (as opposed to asking everyone to use git master), and/or a stable branch which will only cherry-pick changes from master based on certain guidelines. Regards, Haradl -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)