Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <20170506225958.04eb67e1@bifrost.webthing.com>
References: <20170416001241.2437334f@bifrost.webthing.com> <ff5b1402-a5f2-23e3-e3c5-a335b3132292@kippdata.de>
 <CAKQ1sVOPUgCnhvkoE_EaV+CzoHWZX7wquOq_OJYYu_YhH7_J4A@mail.gmail.com>
 <20170419164525.334caa58@bifrost.webthing.com> <CACsi253SR1O2JtJmgp+7o1-0gJ2Lp=drmVHH-ySFvjdm+m6Hgw@mail.gmail.com>
 <CACsi253u6n=iUhtWv_uUOiu6KyYGvaQnLfGc7EjaNxLZdXVeng@mail.gmail.com>
 <CACsi251Hypu4uHeHuS9jXkVt-dA=iLw-HNVTqEDh5gc6L5goEQ@mail.gmail.com>
 <1493197622.28737.120.camel@mimir.webthing.com> <CACsi251LH79T97gmsbCDmyWjnRsE_HFK-JCzcYvBM9H1GmX4ig@mail.gmail.com>
 <1493465032.28737.161.camel@mimir.webthing.com> <20170506225958.04eb67e1@bifrost.webthing.com>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Sat, 6 May 2017 19:54:53 -0500
Message-ID: <CACsi251iYimKwW9OQmw-RNhPmPxvT7pQ-6mPN8aMv5bK840oZQ@mail.gmail.com>
Subject: Re: 1.6.0 release candidates
To: Nick Kew <niq@apache.org>
Cc: APR Developer List <dev@apr.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c0602661688c3054ee4926a
archived-at: Sun, 07 May 2017 00:55:13 -0000

--94eb2c0602661688c3054ee4926a
Content-Type: text/plain; charset=UTF-8

So my blocking concern is that APR has never shipped an unready, disabled
by default feature. I don't mind not ready for prime time but we
traditionally called such things alpha or beta releases. I am not worried
about a specific platform, but about the wide range of unreviewed
architectures.

The Solaris report seemed concerning. Many of my AIX observations were
incorrect libtool flavor detection for DSO and subordinate test program
invocation, but some weren't. (Can't test if mutex returns immediately.) I
will know Tues if this is entirety a regression or anticipated exception.

I'm afraid BEOS may already be abandoned. The comments about windows
specifics were also concerning, but I have to change gears Sunday back into
that world to start further review.

In short, everything excluding tiimedlock mutexed seems long overdue. This
new mutex feature extension seems hardly ready. I am -1 to have a default
disabled feature, and -0 on releasing this code in its present state.
Suspect it could use a couple months on the bench and a couple more active
reviewers on a breadth of platforms to move it on to a 1.7/2.0 release.

Just my thoughts, excepting your commit inverting a disable for an enable
flag. I think we should finish 1.6 immediately upon reverting this feature
on this branch, which means first forking to 1.7 to preserve it for another
minor release in the not too distant future.

--94eb2c0602661688c3054ee4926a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">So my blocking concern is that APR has never shipped an u=
nready, disabled by default feature. I don&#39;t mind not ready for prime t=
ime but we traditionally called such things alpha or beta releases. I am no=
t worried about a specific platform, but about the wide range of unreviewed=
 architectures.<div dir=3D"auto"><br></div><div dir=3D"auto">The Solaris re=
port seemed concerning. Many of my AIX observations were incorrect libtool =
flavor detection for DSO and subordinate test program invocation, but some =
weren&#39;t. (Can&#39;t test if mutex returns immediately.) I will know Tue=
s if this is entirety a regression or anticipated exception.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">I&#39;m afraid BEOS may already be ab=
andoned. The comments about windows specifics were also concerning, but I h=
ave to change gears Sunday back into that world to start further review.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">In short, everything exclu=
ding tiimedlock mutexed seems long overdue. This new mutex feature extensio=
n seems hardly ready. I am -1 to have a default disabled feature, and -0 on=
 releasing this code in its present state. Suspect it could use a couple mo=
nths on the bench and a couple more active reviewers on a breadth of platfo=
rms to move it on to a 1.7/2.0 release.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Just my thoughts, excepting your commit inverting a disable=
 for an enable flag. I think we should finish 1.6 immediately upon revertin=
g this feature on this branch, which means first forking to 1.7 to preserve=
 it for another minor release in the not too distant future.</div></div>

--94eb2c0602661688c3054ee4926a--