You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2005/08/08 22:32:51 UTC
CTR policy for experimental modules in A2.0?
I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
auth check)... since the module is experimental, can I assume CTR ?
Re: CTR policy for experimental modules in A2.0?
Posted by Ian Holsman <li...@holsman.net>.
Jim Jagielski wrote:
> I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
> exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
> auth check)... since the module is experimental, can I assume CTR ?
>
Hey Jim
can you post the patch ?
while this discussion about RTC/CTR is fantastic and all..
I'd love to get the patch into the code..
so post it.
we can all review it onlist (like the good ol days) and give you some
+/- 1's /feedback on here.
(speaking with my ldap-user hat on)
Re: CTR policy for experimental modules in A2.0?
Posted by r....@t-online.de.
Joe Orton wrote:
> On Mon, Aug 08, 2005 at 01:46:30PM -0700, Paul Querna wrote:
>
>>Bill Stoddard wrote:
>>
>>>Jim Jagielski wrote:
>>>
>>>
>>>>I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
>>>>exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
>>>>auth check)... since the module is experimental, can I assume CTR ?
>>>
>>>+1
>>>
>>>IMO, imposing RTC on experimental modules is counter productive.
>>
>>-1 (vote, not veto).
>
>
> Likewise -1.
Also -1 from my side.
>
>
>>It should be reviewed, regardless of being on applicable to 2.0. Put it
>>in the status file, just like everything else. I feel that being in
>>'experimental' is not a good excuse for not requiring the same level of
>>review as any other change.
>
>
> Plus, the "experimental"-ness of any 2.0 modules is largely meaningless
> to users, they just --enable-auth-ldap and don't care about the module
> directory structure.
+1
Regards
Rüdiger
Re: CTR policy for experimental modules in A2.0?
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Aug 08, 2005 at 01:46:30PM -0700, Paul Querna wrote:
> Bill Stoddard wrote:
> > Jim Jagielski wrote:
> >
> >> I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
> >> exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
> >> auth check)... since the module is experimental, can I assume CTR ?
> >
> > +1
> >
> > IMO, imposing RTC on experimental modules is counter productive.
>
> -1 (vote, not veto).
Likewise -1.
> It should be reviewed, regardless of being on applicable to 2.0. Put it
> in the status file, just like everything else. I feel that being in
> 'experimental' is not a good excuse for not requiring the same level of
> review as any other change.
Plus, the "experimental"-ness of any 2.0 modules is largely meaningless
to users, they just --enable-auth-ldap and don't care about the module
directory structure.
joe
Re: CTR policy for experimental modules in A2.0?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 8, 2005 1:46:30 PM -0700 Paul Querna <ch...@force-elite.com>
wrote:
> -1 (vote, not veto).
-1 as well.
> It should be reviewed, regardless of being on applicable to 2.0. Put it
> in the status file, just like everything else. I feel that being in
> 'experimental' is not a good excuse for not requiring the same level of
> review as any other change.
+1 to this sentiment. -- justin
Re: RTC killed the open source project
Posted by Andreas Steinmetz <as...@domdv.de>.
Paul Querna wrote:
> Andreas Steinmetz wrote:
>
>>Paul Querna wrote:
>>
>>
>>>Oh Please, don't give me that crap. Submit a patch, and it will get in
>>>the next release. The bug you mention does not have a patch. If it
>>>matters so much to you, fix it yourself.
>>
>>
>>Nice attitude. So the bug reporter must be a "I know how to fix
>>everything in the world because I'm the wizard of every tool around"
>>type of human being?
>
>
> No, because I don't know how to fix it, nor do I have the resources to
> fix it(AMD64? I wish..). If its important enough, someone that has the
> resources (time, experience, knowledge) will come along and fix it.
>
> My attitude isn't that the reporter should fix it, its just that as a
> developer who doesn't have an AMD64 system, it would be a waste of my
> time to look at this specific bug, as it sounds pretty specific to both
> AMD64 and SuSe.
Not SuSE, it is AMD64 in general as a Bi-Arch system (32bit libs in
*/lib and 64bit libs in */lib64). And I guess we'll have to wait for
someone with auto*-Tools knowledge and an AMD64 to resolve the problem.
--
Andreas Steinmetz SPAMmers use robotrap@domdv.de
Re: RTC killed the open source project
Posted by Paul Querna <ch...@force-elite.com>.
Andreas Steinmetz wrote:
> Paul Querna wrote:
>
>>Oh Please, don't give me that crap. Submit a patch, and it will get in
>>the next release. The bug you mention does not have a patch. If it
>>matters so much to you, fix it yourself.
>
>
> Nice attitude. So the bug reporter must be a "I know how to fix
> everything in the world because I'm the wizard of every tool around"
> type of human being?
No, because I don't know how to fix it, nor do I have the resources to
fix it(AMD64? I wish..). If its important enough, someone that has the
resources (time, experience, knowledge) will come along and fix it.
My attitude isn't that the reporter should fix it, its just that as a
developer who doesn't have an AMD64 system, it would be a waste of my
time to look at this specific bug, as it sounds pretty specific to both
AMD64 and SuSe.
-Paul
Re: RTC killed the open source project
Posted by Andreas Steinmetz <as...@domdv.de>.
Paul Querna wrote:
> Oh Please, don't give me that crap. Submit a patch, and it will get in
> the next release. The bug you mention does not have a patch. If it
> matters so much to you, fix it yourself.
Nice attitude. So the bug reporter must be a "I know how to fix
everything in the world because I'm the wizard of every tool around"
type of human being?
--
Andreas Steinmetz SPAMmers use robotrap@domdv.de
Re: RTC killed the open source project
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Brad Nicholes wrote:
> But on the other hand, there shouldn't be a reason why apr-util can't be
> released at anytime regardless of why. If there is a linkage between
> apr 1.2.0 and apr-util 1.2.0 that just means that they happen to be
> released at the same time. There is nothing sacred about what the
> version numbers happen to be or if they happen to be the same. If
> apr-dbd isn't ready to be released yet but apr-util is, then where is
> the real hold up?
apr-dbd is part of apr-util, it isn't its own separate library, it has
to be released as part of apr-util.
-garrett
Re: RTC killed the open source project
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Brad Nicholes wrote:
> But on the other hand, there shouldn't be a reason why apr-util can't be
> released at anytime regardless of why. If there is a linkage between
> apr 1.2.0 and apr-util 1.2.0 that just means that they happen to be
> released at the same time. There is nothing sacred about what the
> version numbers happen to be or if they happen to be the same. If
> apr-dbd isn't ready to be released yet but apr-util is, then where is
> the real hold up?
apr-dbd is part of apr-util, it isn't its own separate library, it has
to be released as part of apr-util.
-garrett
Re: Single-maintainer platforms was Re: RTC killed the open source
project
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Justin Erenkrantz wrote:
> --On August 9, 2005 7:54:17 PM +0200 Graham Leggett <mi...@sharp.fm>
> wrote:
>
>> within apr (like libtool and some other files). It would be nice if
>> apr-util
>> could access apr cleanly via the apr-1-config mechanism, rather than
>> depending on build artifacts. This has been on my plate to fix for a
>> while,
>> but time has not been on my side.
>
>
> It's done that since before we went 1.0. (I almost always build
> apr-util from an installed apr.) Or, is there something else? -- justin
I think you need apr in order to do a buildconf for apr-util, so if
you're building right out of svn it is needed, but perhaps not if you're
just compiling a release version.
-garrett
Re: Single-maintainer platforms was Re: RTC killed the open source
project
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 9, 2005 7:54:17 PM +0200 Graham Leggett <mi...@sharp.fm> wrote:
> within apr (like libtool and some other files). It would be nice if apr-util
> could access apr cleanly via the apr-1-config mechanism, rather than
> depending on build artifacts. This has been on my plate to fix for a while,
> but time has not been on my side.
It's done that since before we went 1.0. (I almost always build apr-util from
an installed apr.) Or, is there something else? -- justin
Re: Single-maintainer platforms was Re: RTC killed the open source
project
Posted by Graham Leggett <mi...@sharp.fm>.
Justin Erenkrantz wrote:
> But, we're not trying to do an apr-util release!
>
> Our policy (discussed before here on dev@) is that apr and apr-util are
> independent libraries that need not share version numbers or release
> cycles.
>
> Hence, Netware is blocking the apr (not apr-util!) release when every
> other platform allows them to be split up properly.
>
> If anyone else could fix Netware, we would have done so. -- justin
Releasing an apr-util alongside apr is a simple thing to do, so to say
that it's "blocking" an apr release is a bit extreme.
However making sure that apr-util and apr can be released separately is
a good thing.
Apr-util still has some lingering dependancies on the unix build system
within apr (like libtool and some other files). It would be nice if
apr-util could access apr cleanly via the apr-1-config mechanism, rather
than depending on build artifacts. This has been on my plate to fix for
a while, but time has not been on my side.
Regards,
Graham
--
Re: Single-maintainer platforms was Re: RTC killed the open
source project
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 9, 2005 11:17:31 AM -0600 Brad Nicholes <BN...@novell.com>
wrote:
> But that is beside the point. Nothing should block a release for an
> extended period of time which apr-dbd apparently is. There are
> technical reasons why apr and apr-util is built together into a single
> library on the NetWare platform. 99% of the time this is not a problem.
> But in this one case because of the refactoring of the LDAP code within
> apr-util, changes in apr-util affected the build files for apr on
> NetWare.
But, we're not trying to do an apr-util release!
Our policy (discussed before here on dev@) is that apr and apr-util are
independent libraries that need not share version numbers or release cycles.
Hence, Netware is blocking the apr (not apr-util!) release when every other
platform allows them to be split up properly.
If anyone else could fix Netware, we would have done so. -- justin
Single-maintainer platforms was Re: RTC killed the open source
project
Posted by Brad Nicholes <BN...@novell.com>.
But that is beside the point. Nothing should block a release for an
extended period of time which apr-dbd apparently is. There are
technical reasons why apr and apr-util is built together into a single
library on the NetWare platform. 99% of the time this is not a problem.
But in this one case because of the refactoring of the LDAP code within
apr-util, changes in apr-util affected the build files for apr on
NetWare.
NetWare is not blocking a release of anything. It's code is ready to
go. It is the fact that apr-dbd API's are not fully cooked and ready to
be released that is blocking things. There have been other changes
within apr-util besides the NetWare build code that should be released
as well. But they also can't be released because of apr-dbd. If
apr-dbd is going to continue to hold up a release of apr-util for any
reason, it needs to be pulled off into it's own -dev branch until it is
ready.
Brad
>
>>>> On Tuesday, August 09, 2005 at 10:45 am, in message
> <83...@Justin-Erenkrantzs-Computer.local>, Justin
> Erenkrantz
> <ju...@erenkrantz.com> wrote:
>
>No, the problem is that Netware's build system is broken. It
shouldn't be
>tied together by version. Keeping them tied together breaks our
compatibility
>rules. We should always be able to mix and match apr and apr-util
versions.
>
>Since Netware only has one maintainer, if it's not important for you
to fix
>it, then it's not important enough to block a release. -- justin
Single-maintainer platforms was Re: RTC killed the open source project
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 9, 2005 10:38:28 AM -0600 Brad Nicholes <BN...@novell.com>
wrote:
> But on the other hand, there shouldn't be a reason why apr-util can't be
> released at anytime regardless of why. If there is a linkage between
> apr 1.2.0 and apr-util 1.2.0 that just means that they happen to be
> released at the same time. There is nothing sacred about what the
> version numbers happen to be or if they happen to be the same. If
> apr-dbd isn't ready to be released yet but apr-util is, then where is
> the real hold up?
No, the problem is that Netware's build system is broken. It shouldn't be
tied together by version. Keeping them tied together breaks our compatibility
rules. We should always be able to mix and match apr and apr-util versions.
Since Netware only has one maintainer, if it's not important for you to fix
it, then it's not important enough to block a release. -- justin
Re: RTC killed the open source project
Posted by Brad Nicholes <BN...@novell.com>.
But on the other hand, there shouldn't be a reason why apr-util can't be
released at anytime regardless of why. If there is a linkage between
apr 1.2.0 and apr-util 1.2.0 that just means that they happen to be
released at the same time. There is nothing sacred about what the
version numbers happen to be or if they happen to be the same. If
apr-dbd isn't ready to be released yet but apr-util is, then where is
the real hold up?
Brad
>>> On Tuesday, August 09, 2005 at 10:26 am, in message
<42...@force-elite.com>, Paul Querna <ch...@force-elite.com>
wrote:
> Brad Nicholes wrote:
>>>>>On Tuesday, August 09, 2005 at 10:16 am, in message
>>
>> <20...@redhat.com>, jorton@redhat.com wrote:
>>
>>>Or just release as-is, if nobody is going to fix the Netware build
>>
>> then
>>
>>>Netware won't work, big deal. All three Netware users can write in
>>
>> and
>>
>>>ask for their money back :)
>>>
>>>joe
>>
>>
>> Oh come on, it's not the NetWare build process that is holding the
>> release of apr-util 1.2.0 back, it is the stability of apr-dbd.
>
>
> It is, since I only wanted to Release APR 1.2.0, and not APR-Util.
The
> forcing of linked versions is a problem IMO.
Re: RTC killed the open source project
Posted by Brad Nicholes <BN...@novell.com>.
But on the other hand, there shouldn't be a reason why apr-util can't be
released at anytime regardless of why. If there is a linkage between
apr 1.2.0 and apr-util 1.2.0 that just means that they happen to be
released at the same time. There is nothing sacred about what the
version numbers happen to be or if they happen to be the same. If
apr-dbd isn't ready to be released yet but apr-util is, then where is
the real hold up?
Brad
>>> On Tuesday, August 09, 2005 at 10:26 am, in message
<42...@force-elite.com>, Paul Querna <ch...@force-elite.com>
wrote:
> Brad Nicholes wrote:
>>>>>On Tuesday, August 09, 2005 at 10:16 am, in message
>>
>> <20...@redhat.com>, jorton@redhat.com wrote:
>>
>>>Or just release as-is, if nobody is going to fix the Netware build
>>
>> then
>>
>>>Netware won't work, big deal. All three Netware users can write in
>>
>> and
>>
>>>ask for their money back :)
>>>
>>>joe
>>
>>
>> Oh come on, it's not the NetWare build process that is holding the
>> release of apr-util 1.2.0 back, it is the stability of apr-dbd.
>
>
> It is, since I only wanted to Release APR 1.2.0, and not APR-Util.
The
> forcing of linked versions is a problem IMO.
Release dependencies (Re: RTC killed the open source project)
Posted by Nick Kew <ni...@webthing.com>.
OK, we allegedly have:
- 2.2 waiting on netware
- netware waiting on apr-util 1.2
- apr-util 1.2 waiting on apr_dbd
'Twas I who asked for the apr-util delay at apachecon.
But in my post to dev@apr on 3rd August, I thought I was making
it clear that I no longer wish to hold it up. So, apr-util 1.2
with apr_dbd as-is has a green light from here.
Anything else holding us back?
--
Nick Kew
Re: RTC killed the open source project
Posted by Paul Querna <ch...@force-elite.com>.
Brad Nicholes wrote:
>>>>On Tuesday, August 09, 2005 at 10:16 am, in message
>
> <20...@redhat.com>, jorton@redhat.com wrote:
>
>>Or just release as-is, if nobody is going to fix the Netware build
>
> then
>
>>Netware won't work, big deal. All three Netware users can write in
>
> and
>
>>ask for their money back :)
>>
>>joe
>
>
> Oh come on, it's not the NetWare build process that is holding the
> release of apr-util 1.2.0 back, it is the stability of apr-dbd.
It is, since I only wanted to Release APR 1.2.0, and not APR-Util. The
forcing of linked versions is a problem IMO.
Re: RTC killed the open source project
Posted by Paul Querna <ch...@force-elite.com>.
Brad Nicholes wrote:
>>>>On Tuesday, August 09, 2005 at 10:16 am, in message
>
> <20...@redhat.com>, jorton@redhat.com wrote:
>
>>Or just release as-is, if nobody is going to fix the Netware build
>
> then
>
>>Netware won't work, big deal. All three Netware users can write in
>
> and
>
>>ask for their money back :)
>>
>>joe
>
>
> Oh come on, it's not the NetWare build process that is holding the
> release of apr-util 1.2.0 back, it is the stability of apr-dbd.
It is, since I only wanted to Release APR 1.2.0, and not APR-Util. The
forcing of linked versions is a problem IMO.
Re: RTC killed the open source project
Posted by Brad Nicholes <BN...@novell.com>.
>>> On Tuesday, August 09, 2005 at 10:16 am, in message
<20...@redhat.com>, jorton@redhat.com wrote:
> Or just release as-is, if nobody is going to fix the Netware build
then
> Netware won't work, big deal. All three Netware users can write in
and
> ask for their money back :)
>
> joe
Oh come on, it's not the NetWare build process that is holding the
release of apr-util 1.2.0 back, it is the stability of apr-dbd.
Brad
Re: RTC killed the open source project
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Aug 09, 2005 at 09:05:45AM -0700, Paul Querna wrote:
> The current blocking issue in APR & APR-Util is that we can *only*
> release apr and apr-util of the exact same version number, due to
> problems in the Netware build system. This means to release APR 1.2.0,
> we must release APR-Util 1.2.0. This is currently a problem, since
> APR-Util is in flux from apr-dbd. So, we either fix the Netware build
> (I haven't a clue how), or we wait for apr-dbd to become more stable.
Or just release as-is, if nobody is going to fix the Netware build then
Netware won't work, big deal. All three Netware users can write in and
ask for their money back :)
joe
Re: RTC killed the open source project
Posted by Brad Nicholes <BN...@novell.com>.
>>> On Tuesday, August 09, 2005 at 10:05 am, in message
<42...@force-elite.com>, chip@force-elite.com wrote:
> The current blocking issue in APR & APR-Util is that we can *only*
> release apr and apr-util of the exact same version number, due to
> problems in the Netware build system. This means to release APR
1.2.0,
> we must release APR-Util 1.2.0. This is currently a problem, since
> APR-Util is in flux from apr-dbd. So, we either fix the Netware
build
> (I haven't a clue how), or we wait for apr-dbd to become more
stable.
>
> -Paul
Or we push apr-dbd off into a -dev branch so that we can release
apr-util 1.2.0
Brad
Re: RTC killed the open source project
Posted by Paul Querna <ch...@force-elite.com>.
Andreas Steinmetz wrote:
> Aaron Bannert wrote:
>
>>What other branches are CTR? 1.3? 2.0?
>>
>>Dependency on any outside library, APR included, is going to
>>cause dependency on that library's release cycle. Stagnation
>>happened after 2.0 was released, however.
>>
>>On another note, if APR is the problem, then why are we even
>>talking about branching 2.2 before APR is fixed?
>
Because, for the most part, APR isn't a problem. As the RM for 2.2, I
wanted a new APR release to fix a few platform specific critical bugs
(like, pollsets on Solaris 10). HTTPD can easily go forward with the
knowledge that some things just wont work until a new APR release is done.
> Hmm, yes,
> I did hit an apr-util bug yesterday, looked it up in bugzilla and: it is
> filed in there for more than a year (bug 28205). So if there is a
> release dependency on apr abandon all hope :-(
Oh Please, don't give me that crap. Submit a patch, and it will get in
the next release. The bug you mention does not have a patch. If it
matters so much to you, fix it yourself.
The current blocking issue in APR & APR-Util is that we can *only*
release apr and apr-util of the exact same version number, due to
problems in the Netware build system. This means to release APR 1.2.0,
we must release APR-Util 1.2.0. This is currently a problem, since
APR-Util is in flux from apr-dbd. So, we either fix the Netware build
(I haven't a clue how), or we wait for apr-dbd to become more stable.
-Paul
Re: RTC killed the open source project
Posted by Andreas Steinmetz <as...@domdv.de>.
Aaron Bannert wrote:
> What other branches are CTR? 1.3? 2.0?
>
> Dependency on any outside library, APR included, is going to
> cause dependency on that library's release cycle. Stagnation
> happened after 2.0 was released, however.
>
> On another note, if APR is the problem, then why are we even
> talking about branching 2.2 before APR is fixed?
Hmm, yes,
I did hit an apr-util bug yesterday, looked it up in bugzilla and: it is
filed in there for more than a year (bug 28205). So if there is a
release dependency on apr abandon all hope :-(
--
Andreas Steinmetz SPAMmers use robotrap@domdv.de
Re: RTC killed the open source project
Posted by Aaron Bannert <aa...@clove.org>.
What other branches are CTR? 1.3? 2.0?
Dependency on any outside library, APR included, is going to
cause dependency on that library's release cycle. Stagnation
happened after 2.0 was released, however.
On another note, if APR is the problem, then why are we even
talking about branching 2.2 before APR is fixed?
-aaron
On Aug 8, 2005, at 11:31 PM, Roy T. Fielding wrote:
> On Aug 8, 2005, at 10:55 PM, Aaron Bannert wrote:
>
>
>> I can't believe you guys are still debating the merits of RTC over
>> CTR
>> after all this time. RTC killed the momentum in this project a
>> long time
>> ago.
>>
>
> That doesn't make sense, Aaron. The other branches are CTR and
> I don't see anyone making releases of those either. We were
> operating in RTC mode for the first year of Apache and that was
> our most productive time in terms of number of releases.
>
> Personally, I think what is killing momentum is the number of
> single-developer platforms we claim to support that end up dragging
> the release cycle beyond the capacity of any single RM. That's why
> I haven't driven a release since 1.3. APR just makes it worse.
> Please, if you want to help, don't bicker about RTC -- just
> create a working APR release so that we can do an httpd release.
>
> ....Roy
>
>
Re: RTC killed the open source project
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Aug 8, 2005, at 10:55 PM, Aaron Bannert wrote:
> I can't believe you guys are still debating the merits of RTC over CTR
> after all this time. RTC killed the momentum in this project a long
> time
> ago.
That doesn't make sense, Aaron. The other branches are CTR and
I don't see anyone making releases of those either. We were
operating in RTC mode for the first year of Apache and that was
our most productive time in terms of number of releases.
Personally, I think what is killing momentum is the number of
single-developer platforms we claim to support that end up dragging
the release cycle beyond the capacity of any single RM. That's why
I haven't driven a release since 1.3. APR just makes it worse.
Please, if you want to help, don't bicker about RTC -- just
create a working APR release so that we can do an httpd release.
....Roy
Re: RTC killed the open source project
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Aug 9, 2005, at 11:28 AM, Aaron Bannert wrote:
> I'm not talking about 2.2. I'm talking about a severe slowdown in the
> pace of development on this entire project.
Less talk, more do.
> And it sounds like you've been feeling the effects of all the red tape
> too, with being fed up trying to follow through with a release.
>
> There are two separate issues:
>
> * The difficulty in *producing* releases is due to RMs being too afraid
> to make releases that aren't perfect. This phobia is a disease,
> because
> it prevents the release-early-release-often motto from happening.
Yes, but that doesn't prevent you from being the RM.
> * The difficulty in *making progress toward a releasable repository* is
> being caused by the STATUS file bottleneck. The STATUS file
> bottleneck
> is caused because we have Review-Then-Commit rules set up, which
> means everyone has to serialize EVERY CHANGE on that file. (You're
> talking to the thread programming guy here, remember? That's a point
> of contention. :)
I still don't know WTF you are talking about. RTC only applies
to the 1.3 and 2.0 branches right now, neither of which have seen
active development for years because we don't want them to be
actively developed. The only reason we have a STATUS file is
so that the current RM can keep track of what has been proposed
and reviewed without searching the mail archives. We could switch
over to Jira and do the same automatically (assuming it didn't
keel over and die from the load), but the STATUS file is supposed
to be the RM's to-do list, not everyone's bag of concerns. STATUS
doesn't prevent anyone from cutting a new release tarball.
> RTC came with good intentions (higher quality code), but it's clear now
> that it's not working and it needs to change.
RTC is working fine. What isn't working is the lack of releases
on the CTR branches, which is the only reason people still complain
about slow 2.0 releases (because there are no other 2.x releases).
I can't be RM right now because I am going on vacation next week.
If I were RM, then I would simply arrange the tags such that some
set of revisions worked and cut a tarball. If apr-util doesn't
work, revert it to a fixed version. If Netware doesn't work, remove
it from the list of platforms. If win32 can't be built by the RM,
then discard it as irrelevant. Cut the tarball and vote. If that
doesn't pass, fix the errors, cut another tarball, and vote. Keep
going until a release is made.
....Roy
Re: RTC killed the open source project
Posted by Aaron Bannert <aa...@clove.org>.
I'm not talking about 2.2. I'm talking about a severe slowdown in the
pace of development on this entire project.
And it sounds like you've been feeling the effects of all the red tape
too, with being fed up trying to follow through with a release.
There are two separate issues:
* The difficulty in *producing* releases is due to RMs being too afraid
to make releases that aren't perfect. This phobia is a disease,
because
it prevents the release-early-release-often motto from happening.
* The difficulty in *making progress toward a releasable repository* is
being caused by the STATUS file bottleneck. The STATUS file
bottleneck
is caused because we have Review-Then-Commit rules set up, which
means everyone has to serialize EVERY CHANGE on that file. (You're
talking to the thread programming guy here, remember? That's a point
of contention. :)
(It's interesting to note that SVN is a parallel development version
control engine, but RTC forces us to serialize all our changes.
Maybe
we should start using SCCS.)
RTC came with good intentions (higher quality code), but it's clear now
that it's not working and it needs to change.
-aaron
On Aug 9, 2005, at 9:47 AM, Justin Erenkrantz wrote:
> --On August 9, 2005 8:17:37 AM -0700 Aaron Bannert
> <aa...@clove.org> wrote:
>
>
>
>> I've been trying to speed up the release cycles for years, but
>> it's only gotten slower with all the red tape.
>>
>>
>
> Where have you been when we've done releases in the last few years?
>
>
>
>> The slow release cycles are just another symptom of a broken process,
>> they are not the cause.
>>
>>
>
> If you want to place a cause on why 2.2 hasn't been released, I
> feel that there is only one real reason. I gave up on trying to do
> 2.1/2.2 releases because I got fed up with having every release
> blocked for illegitimate reasons. Paul ran into the exact same
> roadblocks; but he's probably too nice to admit it.
>
> The 'slow release cycle' has *nothing* to do with CTR or RTC. --
> justin
>
>
>
Re: RTC killed the open source project
Posted by Brad Nicholes <BN...@novell.com>.
>
>>>> On Tuesday, August 09, 2005 at 10:47 am, in message
> <B6...@Justin-Erenkrantzs-Computer.local>,
> justin@erenkrantz.com wrote:
>
>If you want to place a cause on why 2.2 hasn't been released, I feel
that
>there is only one real reason. I gave up on trying to do 2.1/2.2
releases
>because I got fed up with having every release blocked for
illegitimate
>reasons. Paul ran into the exact same roadblocks; but he's probably
too nice
>to admit it.
>
>The 'slow release cycle' has *nothing* to do with CTR or RTC. --
justin
But I think the point is that RTC has damped the enthusiasm of many
contributors that would have helped to raise the noise level to push
past the silly blocker reasons.
On a slightly different note, I think that the release of 2.0 had the
same "blocker reasons" problem. The only reason why it was released
when it was (prematurely or not) was due to the fact that the RM was
going to release it no matter what and we would deal with the fall out
later. Some could argue that that was a bad thing for the httpd project
and the ASF. Others could argue that it forced forward progress.
Brad
Re: RTC killed the open source project
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 9, 2005 8:17:37 AM -0700 Aaron Bannert <aa...@clove.org> wrote:
> I've been trying to speed up the release cycles for years, but
> it's only gotten slower with all the red tape.
Where have you been when we've done releases in the last few years?
> The slow release cycles are just another symptom of a broken process,
> they are not the cause.
If you want to place a cause on why 2.2 hasn't been released, I feel that
there is only one real reason. I gave up on trying to do 2.1/2.2 releases
because I got fed up with having every release blocked for illegitimate
reasons. Paul ran into the exact same roadblocks; but he's probably too nice
to admit it.
The 'slow release cycle' has *nothing* to do with CTR or RTC. -- justin
Re: RTC killed the open source project
Posted by Aaron Bannert <aa...@clove.org>.
I've been trying to speed up the release cycles for years, but
it's only gotten slower with all the red tape.
The slow release cycles are just another symptom of a broken process,
they are not the cause.
-aaron
On Aug 9, 2005, at 7:00 AM, Paul Querna wrote:
> Aaron Bannert wrote:
>
>> *** Look at the writing on the wall: RTC killed this project.
>>
>> This year there have only been 3 tarballs released:
>> - 2.1.3 (alpha)
>> - 2.0.53 and 2.0.54
>> - no releases of 1.3
>>
>
> Missing:
> 2.1.4 (alpha)
> 2.1.6 (alpha)
>
> I don't believe changing RTC/CTR policy is the solution to the
> (relatively) slow development. I think pushing for faster stable/dev
> version cycles is.
>
> I would rather release 2.2 'soon', and have to do 2.4 in 6-12 months
> than change the CTR/RTC policy. I think these faster cycles address
> many of your concerns.
>
> -Paul
>
>
Re: RTC killed the open source project
Posted by Paul Querna <ch...@force-elite.com>.
Aaron Bannert wrote:
> *** Look at the writing on the wall: RTC killed this project.
>
> This year there have only been 3 tarballs released:
> - 2.1.3 (alpha)
> - 2.0.53 and 2.0.54
> - no releases of 1.3
Missing:
2.1.4 (alpha)
2.1.6 (alpha)
I don't believe changing RTC/CTR policy is the solution to the
(relatively) slow development. I think pushing for faster stable/dev
version cycles is.
I would rather release 2.2 'soon', and have to do 2.4 in 6-12 months
than change the CTR/RTC policy. I think these faster cycles address
many of your concerns.
-Paul
Re: RTC killed the open source project
Posted by Aaron Bannert <aa...@clove.org>.
On Aug 9, 2005, at 7:40 AM, Nick Kew wrote:
> Jim Jagielski wrote:
>
>
>> I think that RTC has a place, but too often RTC is used as a club
>> to slow down development. Small changes that could easily
>> be made once the code has been committed instead result in
>> cycles of "Wouldn't it be best to do this?" and another
>> round of patch-vote commences.
>>
>
> That kind of discussion is a Good Thing. Well, except when it
> gets bogged down and leads to stalemate. For example, my most
> recent contribution (ap_hook_monitor) benefitted from Jeff's
> improvements to my original suggestion.
That kind of discussion happened MORE with CTR. I used to
read every commit message to see if it touched code that I cared
about, but now every commit message has the same subject ("svn
commit: <useless number> [end of title]") and I have to be
online to update my repository to read STATUS to find out what
needs reviewing. It's all just pointless bureaucracy.
> The trouble with RTC is when things simply languish and
> nothing happens.
>
> Or when someone fixes a simple bug in trunk but can't be arsed
> to backport because RTC is more hassle. I plead guilty to far
> too much of that myself.
It seems to me that the entire project is languishing.
>> in RTC, stuff will
>> stagnate during their offline times; with CTR they can
>> add their code and next week, when unavailable,
>> people can add upon it, improve it, etc... RTC requires
>> a longer time commitment and availability to see
>> things through to the end, tough things with the
>> bursty nature of volunteers.
>>
>
> Yep. But mostly it's finding the time to review other peoples
> contributions, and making sufficient nuisance of oneself to
> get ones own things reviewed.
>
> I think there could be some mileage in a hybrid policy, with
> lazy consensus on simple bugfixes and RTC on any new functionality
> or substantial changes. There's a problem of definition in there,
> but if lazy consensus requires (say) a month in STATUS it gives ample
> time for someone to shout "that's too big - needs proper RTC".
Amusing that you should bring this up. This hybrid approach is
EXACTLY how it was before.
1) Small patches are simply committed to HEAD/trunk
2) Large changes are posted to the mailing list and given a few days
for review and discussion.
3) Everyone trusts everyone else to be reasonable about how they
define "large" and "small", and we err on the side of large.
4) Vetoes (only with a valid technical reason) cause code to be revoked
with a followup discussion about how to solve the veto.
- no more having discussion in STATUS files
- no more red tape for simple backports
- no restrictions on what people are allowed to work on (if they want to
add features to an older version of apache, don't stop them)
-aaron
Re: RTC killed the open source project
Posted by Brad Nicholes <BN...@novell.com>.
>>> On Tuesday, August 09, 2005 at 8:40 am, in message
<42...@webthing.com>, nick@webthing.com wrote:
>
>
> I think there could be some mileage in a hybrid policy, with
> lazy consensus on simple bugfixes and RTC on any new functionality
> or substantial changes. There's a problem of definition in there,
> but if lazy consensus requires (say) a month in STATUS it gives ample
> time for someone to shout "that's too big - needs proper RTC".
+1, I think a month is too long but I am sure that there is a period of time that is sufficient to satisfy lazy consensus as well as RTC. I've seen backport proposals miss releases simply on lack of review even though they had more than enough time in the STATUS file. I've even seen reviewed backports turn out to be problems in a release. Not because of inadequate review but because the only way that the problem was going to be found was through real world testing. "Release early, release often" IMHO is going to shoot down more bugs than "review it in the STATUS file".
Brad
Re: RTC killed the open source project
Posted by Nick Kew <ni...@webthing.com>.
Jim Jagielski wrote:
> I think that RTC has a place, but too often RTC is used as a club
> to slow down development. Small changes that could easily
> be made once the code has been committed instead result in
> cycles of "Wouldn't it be best to do this?" and another
> round of patch-vote commences.
That kind of discussion is a Good Thing. Well, except when it
gets bogged down and leads to stalemate. For example, my most
recent contribution (ap_hook_monitor) benefitted from Jeff's
improvements to my original suggestion.
The trouble with RTC is when things simply languish and
nothing happens.
Or when someone fixes a simple bug in trunk but can't be arsed
to backport because RTC is more hassle. I plead guilty to far
too much of that myself.
> CTR is better suited towards more volunteer-oriented
> processes, where someone may have a lot of time today
> and tomorrow, but little next week;
I expect many committers fit that description.
> in RTC, stuff will
> stagnate during their offline times; with CTR they can
> add their code and next week, when unavailable,
> people can add upon it, improve it, etc... RTC requires
> a longer time commitment and availability to see
> things through to the end, tough things with the
> bursty nature of volunteers.
Yep. But mostly it's finding the time to review other peoples
contributions, and making sufficient nuisance of oneself to
get ones own things reviewed.
I think there could be some mileage in a hybrid policy, with
lazy consensus on simple bugfixes and RTC on any new functionality
or substantial changes. There's a problem of definition in there,
but if lazy consensus requires (say) a month in STATUS it gives ample
time for someone to shout "that's too big - needs proper RTC".
--
Nick Kew
Re: RTC killed the open source project
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 9, 2005, at 11:24 AM, Aaron Bannert wrote:
> Version control is your friend,
> use it.
>
It is a shame that despite the advantages of svn over cvs for
tags/branches/etc, we are hardly using them effectively.
Re: RTC killed the open source project
Posted by Aaron Bannert <aa...@clove.org>.
No, 2.0 was a moving target because there was lots of active
development and things were getting rapidly fixed and rolled into
tarballs for our beta testers to pound on. There were easily 3 times
as many developers working on 2.0 than there are now.
Moving Target >> Stagnation
Bill's changes were numerous but each was individually reviewable.
The RTC alternative is to post that patches, find 2 other buddies to
hold hands with while crossing the street, look both ways, hold your
breath, then commit the big megapatch. Version control is your friend,
use it.
-aaron
On Aug 9, 2005, at 7:46 AM, Mads Toftum wrote:
> On Tue, Aug 09, 2005 at 09:11:56AM -0400, Jim Jagielski wrote:
>
>> I think that RTC has a place, but too often RTC is used as a club
>> to slow down development. Small changes that could easily
>> be made once the code has been committed instead result in
>> cycles of "Wouldn't it be best to do this?" and another
>> round of patch-vote commences.
>>
>>
> All fine in theory, but wrowe who is the one suggesting CTR on
> those two
> modules certainly wasn't suggesting small changes - there was what
> - 20
> commits in the proxy/cache code the other day?
> The real trick is how you define the difference between small,
> relatively safe changes and complete rewrites of large chunks of code.
> 2.0 took very long to settle because it was very much a moving
> target, I
> would hate for the same to keep happening with a 2.2 release.
>
> vh
>
> Mads Toftum
> --
> `Darn it, who spiked my coffee with water?!' - lwall
>
>
Re: RTC killed the open source project
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:46 AM 8/9/2005, Mads Toftum wrote:
>On Tue, Aug 09, 2005 at 09:11:56AM -0400, Jim Jagielski wrote:
>> I think that RTC has a place, but too often RTC is used as a club
>> to slow down development. Small changes that could easily
>> be made once the code has been committed instead result in
>> cycles of "Wouldn't it be best to do this?" and another
>> round of patch-vote commences.
>>
>All fine in theory, but wrowe who is the one suggesting CTR on those two
>modules certainly wasn't suggesting small changes - there was what - 20
>commits in the proxy/cache code the other day?
Uhm, we might be getting a bit confused. ldap and cache weren't
declared stable, they are experimental in 2.0 - and it's only the
experimental modules that are suggested for pure CTR by Jim,
FirstBill and myself.
And this will probably go away if we stop rolling experimental
code in with G.A. release tarballs. New experimental modules
should be completely tested and adopted as stand-alone by new
testers/users, before code like that goes out the door with the
httpd release. Our branches make this pretty straightforward now.
As much as I'd like to claim that the existing 2.0 proxy code
bordered on experimental ;-)... I won't suggest it should be RTC
unless we change the policy across the board. And these changes,
just like Jeff's original 3-mode request body handling patch,
need scrutiny. The double-headers termination bug that Joe's
regression tests picked up is a case in point.
Bill
Re: RTC killed the open source project
Posted by Mads Toftum <ma...@toftum.dk>.
On Tue, Aug 09, 2005 at 09:11:56AM -0400, Jim Jagielski wrote:
> I think that RTC has a place, but too often RTC is used as a club
> to slow down development. Small changes that could easily
> be made once the code has been committed instead result in
> cycles of "Wouldn't it be best to do this?" and another
> round of patch-vote commences.
>
All fine in theory, but wrowe who is the one suggesting CTR on those two
modules certainly wasn't suggesting small changes - there was what - 20
commits in the proxy/cache code the other day?
The real trick is how you define the difference between small,
relatively safe changes and complete rewrites of large chunks of code.
2.0 took very long to settle because it was very much a moving target, I
would hate for the same to keep happening with a 2.2 release.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
Re: RTC killed the open source project
Posted by Aaron Bannert <aa...@clove.org>.
I definitely agree that RTC requires a lengthy time commitment
that many of us simply can't give, while CTR allows for much more
fluid development process. This is the difference between a full-time
day job and a hobby.
How many of you only spend less than an hour a day doing httpd dev work?
-aaron
On Aug 9, 2005, at 6:11 AM, Jim Jagielski wrote:
>
> On Aug 9, 2005, at 1:55 AM, Aaron Bannert wrote:
>
>
>> I can't believe you guys are still debating the merits of RTC over
>> CTR
>> after all this time. RTC killed the momentum in this project a
>> long time
>> ago.
>>
>>
>> The RTC experiment was tried and has failed. Can we please
>> go back to the way things were, back when this project was fun?
>>
>>
>
> I think that RTC has a place, but too often RTC is used as a club
> to slow down development. Small changes that could easily
> be made once the code has been committed instead result in
> cycles of "Wouldn't it be best to do this?" and another
> round of patch-vote commences.
>
> CTR is better suited towards more volunteer-oriented
> processes, where someone may have a lot of time today
> and tomorrow, but little next week; in RTC, stuff will
> stagnate during their offline times; with CTR they can
> add their code and next week, when unavailable,
> people can add upon it, improve it, etc... RTC requires
> a longer time commitment and availability to see
> things through to the end, tough things with the
> bursty nature of volunteers.
>
>
Re: RTC killed the open source project
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 9, 2005, at 1:55 AM, Aaron Bannert wrote:
> I can't believe you guys are still debating the merits of RTC over CTR
> after all this time. RTC killed the momentum in this project a long
> time
> ago.
>
>
> The RTC experiment was tried and has failed. Can we please
> go back to the way things were, back when this project was fun?
>
I think that RTC has a place, but too often RTC is used as a club
to slow down development. Small changes that could easily
be made once the code has been committed instead result in
cycles of "Wouldn't it be best to do this?" and another
round of patch-vote commences.
CTR is better suited towards more volunteer-oriented
processes, where someone may have a lot of time today
and tomorrow, but little next week; in RTC, stuff will
stagnate during their offline times; with CTR they can
add their code and next week, when unavailable,
people can add upon it, improve it, etc... RTC requires
a longer time commitment and availability to see
things through to the end, tough things with the
bursty nature of volunteers.
RTC killed the open source project
Posted by Aaron Bannert <aa...@clove.org>.
I can't believe you guys are still debating the merits of RTC over CTR
after all this time. RTC killed the momentum in this project a long time
ago.
* Quality and stability are emergent properties, not processes:
Making releases is a natural step in the bug-fixing cycle. However,
the STATUS file adds a whole bunch of unnecessary red tape
to the change review process which makes it very difficult to
"release early and release often". This slows the wheels of
development and the rate of bug finding.
* RTC reduces the number of eyes looking for bugs:
The STATUS file does not impart perfection. It keeps track of each
patch's reviewers, but doesn't guarantee thorough reviews. Due to
all the hoops that a reviewer must jump through in order to "review"
a patch these days, it is inevitable that fewer people make the effort.
* RTC means we don't trust our committers.
Why do we have committers if we don't trust them to commit code?
We trust them enough to vote, but only the buddy system for commits?
I already trust everyone here to review changes to code they care
about. Forgotten code still suffers bitrot regardless of RTC. The only
difference between now and what we had before is that there are
fewer eyeballs looking at patches and more wasted energy.
* RTC isn't necessary with a proper version control system.
Bugs happen, and with version control they can be easily fixed,
shared with others, and tracked. Use it!
*** Look at the writing on the wall: RTC killed this project.
This year there have only been 3 tarballs released:
- 2.1.3 (alpha)
- 2.0.53 and 2.0.54
- no releases of 1.3
The RTC experiment was tried and has failed. Can we please
go back to the way things were, back when this project was fun?
-aaron
Re: CTR policy for experimental modules in A2.0?
Posted by Paul Querna <ch...@force-elite.com>.
Bill Stoddard wrote:
> Jim Jagielski wrote:
>
>> I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
>> exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
>> auth check)... since the module is experimental, can I assume CTR ?
>>
>
> +1
>
> IMO, imposing RTC on experimental modules is counter productive.
-1 (vote, not veto).
It should be reviewed, regardless of being on applicable to 2.0. Put it
in the status file, just like everything else. I feel that being in
'experimental' is not a good excuse for not requiring the same level of
review as any other change.
-Paul
Re: CTR policy for experimental modules in A2.0?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Bill Stoddard wrote:
> William A. Rowe, Jr. wrote:
>
>> At 03:36 PM 8/8/2005, Bill Stoddard wrote:
>>
>>> Jim Jagielski wrote:
>>>
>>>> I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
>>>> exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
>>>> auth check)... since the module is experimental, can I assume CTR ?
>>>
>>>
>>> +1
>>>
>>> IMO, imposing RTC on experimental modules is counter productive.
>>
>>
>>
>> ++1. Applies to cache and ldap; these have seen huge progress
>> on both 2.0 and trunk, but why stall.
>>
>> I'd move to official declare modules/experimental/ as CTR.
>> Votes? (I'm assuming both Bill's opinion on this is +1.)
>>
>
> Yep, I'm +1 on RTC for both cache and ldap/.
Rewind, backspace and do over...
Yep, I'm +1 on CTR for both cache and ldap. RTC for everything else in the 2.0 tree that is not experimental.
I am solely interested in converging on the most stable, functional code in as short a period of time as
possible. If CTR on cache and ldap turn either of them into dumping ground for untested code, I will quickly
switch back to RTC for these components.
Bill
Re: CTR policy for experimental modules in A2.0?
Posted by Brad Nicholes <BN...@novell.com>.
>>> On Monday, August 08, 2005 at 3:23 pm, in message
> Yep, I'm +1 on RTC for both cache and ldap/.
>
> Bill
Did you mean CTR?
Brad
Re: CTR policy for experimental modules in A2.0?
Posted by Bill Stoddard <bi...@wstoddard.com>.
William A. Rowe, Jr. wrote:
> At 03:36 PM 8/8/2005, Bill Stoddard wrote:
>
>>Jim Jagielski wrote:
>>
>>>I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
>>>exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
>>>auth check)... since the module is experimental, can I assume CTR ?
>>
>>+1
>>
>>IMO, imposing RTC on experimental modules is counter productive.
>
>
> ++1. Applies to cache and ldap; these have seen huge progress
> on both 2.0 and trunk, but why stall.
>
> I'd move to official declare modules/experimental/ as CTR.
> Votes? (I'm assuming both Bill's opinion on this is +1.)
>
Yep, I'm +1 on RTC for both cache and ldap/.
Bill
Re: CTR policy for experimental modules in A2.0?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:36 PM 8/8/2005, Bill Stoddard wrote:
>Jim Jagielski wrote:
>>I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
>>exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
>>auth check)... since the module is experimental, can I assume CTR ?
>
>+1
>
>IMO, imposing RTC on experimental modules is counter productive.
++1. Applies to cache and ldap; these have seen huge progress
on both 2.0 and trunk, but why stall.
I'd move to official declare modules/experimental/ as CTR.
Votes? (I'm assuming both Bill's opinion on this is +1.)
Bill
Re: CTR policy for experimental modules in A2.0?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Jim Jagielski wrote:
> I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
> exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
> auth check)... since the module is experimental, can I assume CTR ?
>
+1
IMO, imposing RTC on experimental modules is counter productive.
Bill