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

[Harald Welte]

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)