You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2017/05/19 05:14:19 UTC
[POLL] (Was Re: Et resurrexit tertia die.)
On Mon, Apr 10, 2017 at 4:40 AM, Nick Kew <ni...@apache.org> wrote:
> I think we've done most of 1.6.0, modulo a couple of questionmarks.
>
> Potentially open issues are (in no particular order):
> 1. Mark timedlocks experimental
The underlying question which we haven't resolved, and which our
discussion didn't draw out enough opinions/voices, boils down to this
simple question...
[ ] Release 1.x may include experimental features, disabled by default
[ ] Release 1.x may include experimental features, enabled by default
[ ] Releases don't include experimental features
My underlying assumption is that toggling from experimental to release
would occur in release 1.(x+1), but that's yet another discussion based
on the outcome of this straightforward poll.
.
Re: [POLL] (Was Re: Et resurrexit tertia die.)
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/19/2017 07:14 AM, William A Rowe Jr wrote:
> On Mon, Apr 10, 2017 at 4:40 AM, Nick Kew <ni...@apache.org> wrote:
>> I think we've done most of 1.6.0, modulo a couple of questionmarks.
>>
>> Potentially open issues are (in no particular order):
>> 1. Mark timedlocks experimental
>
> The underlying question which we haven't resolved, and which our
> discussion didn't draw out enough opinions/voices, boils down to this
> simple question...
>
> [ ] Release 1.x may include experimental features, disabled by default
> [ ] Release 1.x may include experimental features, enabled by default
> [ X ] Releases don't include experimental features
But some words of explanation:
The risk I see with experimental features is that it might turn out during stabilization phase, so on the way out of
experimental, that the API isn't right. And this is something we cannot change then afterwards until a new major release.
On the other hand it is sometimes tough to get enough test audience for new features when they are not contained in a
release. But I like to play it safe in this case. Hence my vote.
Regards
Rüdiger
Re: [POLL] (Was Re: Et resurrexit tertia die.)
Posted by Nick Kew <ni...@apache.org>.
On Fri, 19 May 2017 09:15:59 -0500
William A Rowe Jr <wr...@rowe-clan.net> wrote:
> That sounds like a super headache,
It's that already. Stripping out timedlock code for
alien platforms is a huge risk that something as simple
as a typo breaks it all.
--
Nick Kew
Re: [POLL] (Was Re: Et resurrexit tertia die.)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, May 19, 2017 at 4:06 AM, Nick Kew <ni...@apache.org> wrote:
> On Fri, 2017-05-19 at 00:14 -0500, William A Rowe Jr wrote:
>> On Mon, Apr 10, 2017 at 4:40 AM, Nick Kew <ni...@apache.org> wrote:
>> > I think we've done most of 1.6.0, modulo a couple of questionmarks.
>> >
>> > Potentially open issues are (in no particular order):
>> > 1. Mark timedlocks experimental
>>
>> The underlying question which we haven't resolved, and which our
>> discussion didn't draw out enough opinions/voices, boils down to this
>> simple question...
>
> Thanks for resurrecting this. I thought I'd shut up on
> the subject while some folks were likely doing ApacheCon.
>
> In this instance, we're using "experimental" as a euphemism
> for known-to-be-unready. As such, we shouldn't be encouraging
> anyone to use it with a current release, and should probably
> turn it off as a build option. No need to remove it entirely:
> code that is #ifdef'd out with HAVE_TIMEDLOCK will only be
> seen by those who dig deep enough to find it.
Ehhh... --enable-foo ... -D DONT_USE_ME ... difference without
a distinction?
> There's another issue here: the non-unix platforms all have it.
> If we take it out from Unix altogether, we need to remove it
> from them too. Else we're taking the P from APR!
Of course! You don't have a feature in one that doesn't exist in
the other.
> Which brings me to ...
>
>> [ ] Release 1.x may include experimental features, disabled by default
>> [ ] Release 1.x may include experimental features, enabled by default
>> [ *] Releases don't include experimental features
>
> Refined to:
>
> [ ] Releases don't include too-experimental features, but MAY
> include code for them #ifdef'd out.
> [ ] Strip out the offending code altogether for release.
That sounds like a super headache, because now we are backporting
the fixes/enhancements to get the new known-not-ready feature from
the dev branch to an **unused** implementation on the stable branch,
simply to ensure that users aren't mislead by the previously-unready
draft. That sucks :)
Re: [POLL] (Was Re: Et resurrexit tertia die.)
Posted by Nick Kew <ni...@apache.org>.
On Fri, 2017-05-19 at 00:14 -0500, William A Rowe Jr wrote:
> On Mon, Apr 10, 2017 at 4:40 AM, Nick Kew <ni...@apache.org> wrote:
> > I think we've done most of 1.6.0, modulo a couple of questionmarks.
> >
> > Potentially open issues are (in no particular order):
> > 1. Mark timedlocks experimental
>
> The underlying question which we haven't resolved, and which our
> discussion didn't draw out enough opinions/voices, boils down to this
> simple question...
Thanks for resurrecting this. I thought I'd shut up on
the subject while some folks were likely doing ApacheCon.
In this instance, we're using "experimental" as a euphemism
for known-to-be-unready. As such, we shouldn't be encouraging
anyone to use it with a current release, and should probably
turn it off as a build option. No need to remove it entirely:
code that is #ifdef'd out with HAVE_TIMEDLOCK will only be
seen by those who dig deep enough to find it.
There's another issue here: the non-unix platforms all have it.
If we take it out from Unix altogether, we need to remove it
from them too. Else we're taking the P from APR!
Which brings me to ...
> [ ] Release 1.x may include experimental features, disabled by default
> [ ] Release 1.x may include experimental features, enabled by default
> [ *] Releases don't include experimental features
Refined to:
[ ] Releases don't include too-experimental features, but MAY
include code for them #ifdef'd out.
[ ] Strip out the offending code altogether for release.
--
Nick Kew
Re: [POLL] (Was Re: Et resurrexit tertia die.)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, May 19, 2017 at 12:14 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> [ ] Release 1.x may include experimental features, disabled by default
> [ ] Release 1.x may include experimental features, enabled by default
> [+1] Releases don't include experimental features
My own take is that anything default-disabled, or even experimental
at all can be incorporated, reviewed and endorsed based on tests
and observations from 1.x branch builds, no particular 'release' is
needed to advance a new feature of APR, because we simply do
not address users, we interface entirely with developers who really
do know how to use SVN.
I phrased this as a POLL because I believe it is majority-binding,
not a vetoable decision (just as releases themselves cannot be
vetoed.)