[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] chan_sip maintenance mode
From: Matt Fredrickson <creslin () digium ! com>
Date: 2017-10-16 22:58:02
Message-ID: CAHZ_z=yp8O0k__yfLd2soti4VWMYw1FLqrxxStP+xBzy-Y7Apg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Oct 11, 2017 at 7:24 AM, Corey Farrell <git@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
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct \
11, 2017 at 7:24 AM, Corey Farrell <span dir="ltr"><<a \
href="mailto:git@cfware.com" target="_blank">git@cfware.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">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.<br> <br>
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.</blockquote><div><br></div><div>Hey Corey,</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div></div><div><br></div>-- <br><div class="gmail_signature" \
data-smartmail="gmail_signature"><div dir="ltr"><div>Matthew Fredrickson<br>Digium, \
Inc. | Engineering Manager<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - \
USA</div></div></div> </div></div>
--
_____________________________________________________________________
-- 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic