[Asterisk-Dev] build/make environment

Scott Stingel scott at evtmedia.com
Sat May 22 11:02:40 MST 2004


At least in the short run, it would be good to have some method of clearly
understanding the  effect of changes/enhancements that are made to CVS head,
so people who use certain features heavily can know when extensive testing
is needed.

I read each and every change posted to the asterisk-cvs list, but the
comments are often fairly cryptic.

It also might be good to have bugs closed out not by the person who fixes
them immediately, but left open for additional week to allow for
testing/verification.

Finally, certain people could volunteer to be testers in certain areas, and
be notified (somehow) when software in their areas has been changed.

Not sure how all these mechanisms could be implemented - I just know they
seem necessary.  

Regards
Scott Stingel


Scott M. Stingel
President,
Emerging Voice Technology, Inc.
Palo Alto California & London England
www.evtmedia.com 

-----Original Message-----
From: asterisk-dev-admin at lists.digium.com
[mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of Dr. Rich Murphey
Sent: Saturday, May 22, 2004 10:01 AM
To: asterisk-dev at lists.digium.com
Subject: RE: [Asterisk-Dev] build/make environment

I'd be glad to modify whatever I've written to support FreeBSD in order to
take advantage of autoconf.   I believe autoconf would make support for *BSD
easier to achieve and easier to maintain.

Just count on me to modify it accordingly if autoconf is integrated.
Although I'd prefer to use autoconf, I suspect that the asterisk community
prefers work that is integrated into the distribution, so I'm focusing on
what's in CVS head.

Which begs some additional questions...

A practical issue for these features seems to be the stability of
enhancements - there should be no impact on linux stability and performance.
It's virtually necessary to use version control to stabilize the code
through iterative testing, but also necessary to do so outside of the
asterisk CVS in order to avoid impact on testing of the CVS head on linux.
Add to this the need for collaborative development and we have some tricky
choices with regard to the goal of integrating work into the asterisk CVS.

Cheers,
Rich






More information about the asterisk-dev mailing list