On Wed, Oct 11, 2017 at 7:24 AM, Corey Farrell <g...@cfware.com> wrote:
> I propose that we restrict the kind of bugs/patches that are accepted > against chan_sip to only major/critical bugs, regressions and security > fixes. This means rejecting all new features, improvements and most minor > bugs (AKA known limitations) reported against chan_sip. I am not proposing > we reject reports of crashes, deadlocks, major memory leaks, etc. An > exception would be new feature/improvement tickets where JIRA is being used > to coordinate work - ASTERISK-13145 for example. I believe we should allow > people to continue using JIRA for such things, with the understanding that > the feature is not going to be merged into any official Asterisk > branch/release. > > I'm interested in comments on this proposal from other current chan_sip > users or anyone advocating for us. The purpose of this proposal is to > minimize the chance of regressions for existing chan_sip users, not to > coerce anyone into migrating to chan_pjsip. Hey Corey, Sorry for the delayed response - I took a few days off of work. Although we don't use chan_sip as much anymore at Digium, I have a few principled thoughts about your proposal. I agree in that I think it's challenging to accept significant new contributions to chan_sip without a maintainer - but I feel the same way every time I see an app_queue patch on gerrit, frankly speaking. I believe an element of caution should be considered in any contributions that are made to chan_sip without test coverage - even if the change is made to master. But I also think it's pretty easy to revert problematic commits if something comes up. -- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev