[Asterisk-Users] benevolent dictatorship, or inclusive developper community?

asterisk at lists.styx.org asterisk at lists.styx.org
Tue Jan 6 22:36:55 MST 2004


On Tue, Jan 06, 2004 at 10:59:08PM -0600, Tilghman Lesher wrote:
> 
> Some of my patches might not be the best method in the world, but at
> the very least, I put them out there to be commented upon and improved.
> I don't sit back in an armchair proclaiming that I have really great
> patches, but I'm not going to share them unless they're guaranteed to go
> into CVS.  Why do you believe your programming is so great that it
> deserves to go into CVS right away?

Remember, CVS is supposed to be volatile. It is for testing. It is not
for running in production.

This does not mean it should be a free-for-all. But if someone is
turning out a significant amout of changes, and spending a lot of
time on the project, then the best way to get the changes tested
more than just on the developer's box is to get them into CVS.

The development cycle right now looks like:

	0. discuss any proposed change and potential impact it might
	   have.
	1. write a patch
	2. test patch
	3. post patch to bugs.digium.com
	4. try to convince people to download the patch
	   and apply it to their source and test it
	5. try to get Mark to look at the patch
	6. make necessary changes, goto 2 or patch is fine, continue
	7. try to get Mark to import the patch into CVS
	8. check out fresh source and apply any other patches
	   to it, etc. etc. etc.

4 is nearly impossible since you end up spending most of your time
in IRC cajoling people into trying this or that patch when they've
got other things on their plate. 5 and 7 take forever because Mark
is very busy. 8 is a big headache as your local source tree starts
diverging badly very quickly if you're doing any significant amount
of work on the codebase.

As well, 0 which may happen consecutively with 5, is fraught with
problems since it usually consists in /msg'ing Mark on IRC. Hardly
public discussion in which some consensus may be gained.

As a case in point, we were having a discussion recently on IRC.
Bug #587 contains some changes that implement working syslog support,
but removes support for logging directly to files. The design 
decision to be made is:

	- logging directly to files duplicates exisiting functionality
	  in syslog, so is redundant anyways and can be dropped

			or

	- removing such support breaks backwards compatibility
	  and requires sysadmins to learn how to configure syslog (!)
	  which is an extra burden, so it is better to keep it

This type of thing should be debated publicly on the lists, I
think, so that a consensus can be reached...

-w
-- 
/~\  The ASCII Ribbon Campaign
\ /    No HTML/RTF in email
 X     No Word docs in email
/ \  Respect for open standards



More information about the asterisk-users mailing list