Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates
 209.85.215.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D31CB8D9-DF88-40DB-9C21-D37E7829C6E2@jaguNET.com>
References: <D31CB8D9-DF88-40DB-9C21-D37E7829C6E2@jaguNET.com>
Date: Wed, 10 Jul 2013 15:03:38 -0400
Message-ID: 
 <CAKUrXK4xtdxUKdY6jaLr2EB_K_x6Ddhvjs388yc2pYH5J8AWxg@mail.gmail.com>
Subject: Re: [VOTE] Lazy Consensus for 2.4.x backports
From: Jeff Trawick <trawick@gmail.com>
To: Apache HTTP Server Development List <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=089e0160baae6e20eb04e12cefc1

--089e0160baae6e20eb04e12cefc1
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jul 10, 2013 at 2:03 PM, Jim Jagielski <jim@jagunet.com> wrote:

> Pulling this out as a proposal:
>
> I propose that we track all backports in 2.4 STATUS as we currently
> do. Each backport is time-tagged and we operate under a lazy
> consensus. Assuming no -1 votes within 96 hours, the backport
> can be applied to 2.4.x. If the backport gets 3 +1 votes sooner
> than that, then it can be applied asap...
>
> As with ALL patches, any commit can be reverted for good
> technical (or legal) reasons.
>
> [ ] +1: Agree with this proposal (to start post 2.4.5 release)
> [ ] -1: Disagree with this proposal (and why)
>
>
-1

The current process

* works well/appropriately IMO; to me that means pretty good stream of
fixes to 2.4.x without too high a risk of regressions
* has demonstrably resulted in a reasonably small number of regressions so
far across 2.4.x and earlier releases (definitely not zero regressions, but
pretty darn low).

I think that it is a safe assumption that there will be code changes in
stable releases that have had less review if we make this change.  Largely
regression-free stable releases are of crucial importance for
infrastructure software like httpd, more so than getting another
window-size worth of fixes into the release, especially if they've been
looked at less than the others.

If I count right, 80% or more of the fixes potentially in 2.4.next are
already there (I didn't count mod_lua.)  That doesn't seem so bad.
-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

--089e0160baae6e20eb04e12cefc1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Jul 10, 2013 at 2:03 PM, Jim Jagielski <span dir=
=3D"ltr">&lt;<a href=3D"mailto:jim@jagunet.com" target=3D"_blank">jim@jagun=
et.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Pulling this out as a proposal:<br>
<br>
I propose that we track all backports in 2.4 STATUS as we currently<br>
do. Each backport is time-tagged and we operate under a lazy<br>
consensus. Assuming no -1 votes within 96 hours, the backport<br>
can be applied to 2.4.x. If the backport gets 3 +1 votes sooner<br>
than that, then it can be applied asap...<br>
<br>
As with ALL patches, any commit can be reverted for good<br>
technical (or legal) reasons.<br>
<br>
[ ] +1: Agree with this proposal (to start post 2.4.5 release)<br>
[ ] -1: Disagree with this proposal (and why)<br>
<br>
</blockquote></div><br>-1</div><div class=3D"gmail_extra"><br></div><div cl=
ass=3D"gmail_extra">The current process=A0</div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra">* works well/appropriately IMO; to me =
that means pretty good stream of fixes to 2.4.x without too high a risk of =
regressions</div>
<div class=3D"gmail_extra">* has demonstrably resulted in a reasonably smal=
l number of regressions so far across 2.4.x and earlier releases (definitel=
y not zero regressions, but pretty darn low).</div><div class=3D"gmail_extr=
a">
<br></div><div class=3D"gmail_extra">I think that it is a safe assumption t=
hat there will be code changes in stable releases that have had less review=
 if we make this change. =A0Largely regression-free stable releases are of =
crucial importance for infrastructure software like httpd, more so than get=
ting another window-size worth of fixes into the release, especially if the=
y&#39;ve been looked at less than the others.<br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">If I =
count right, 80% or more of the fixes potentially in 2.4.next are already t=
here (I didn&#39;t count mod_lua.) =A0That doesn&#39;t seem so bad.</div><d=
iv class=3D"gmail_extra">
-- <br>Born in Roswell... married an alien...<br><a href=3D"http://emptyham=
mock.com/" target=3D"_blank">http://emptyhammock.com/</a><br>
</div></div>

--089e0160baae6e20eb04e12cefc1--