Single-maintainer platforms was Re: RTC killed the open source project

[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: Single-maintainer platforms was Re: RTC killed the open source project

[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

[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

[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

[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

[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