>>> On 11/29/2007 at 3:32 PM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Thu, Nov 29, 2007 at 11:17:16AM -0700, Brad Nicholes wrote: >> The reason why I am making that suggestion is because if somebody wants a > static version then they should just continue using 3.0.5. > > They will also need the bugfixes we are getting into 3.1.x, and since we > said > we won't maintain the 3.0.x branch anymore then they have no option but to > use > 3.1.x. > > even if we open a maintenance branch for 3.0.x (which I recommend regardless > and will volunteer to support once I acquire the means to do so) there are > other features than plugins which they might need as well, and so that > wouldn't most likely work for all possible cases either. > > last, there is low "cost" in our side on keeping the static libraries around > so I really see no reason to remove them now. (*) > >> Secondly, the static version is tied to an old version of APR 0.9.x which > has never been officially released by the ASF. > > http://www.apache.org/dist/apr/Announcement0.9.html > >> The only supported versions of APR outside of its use within the Apache > httpd server itself are 1.x versions. > > and that is why APR 0.9.x is not dynamically linked and should remain that > way, as there are no binary compatibility warranties of any kind for > external > users like us, even though I am sure that withing ASF no one will dare to > break > ABI compatibility there either as apache 2.0 and 1.3 depend on it and are > both > supported products. > > http://issues.apache.org/bugzilla/show_bug.cgi?id=42992 > >> Since there has been new work in APR 1.2 with regards to the multicast APIs > and other bug fixes and enhancement, it gets increasingly risky to stick with > an old pre-release version of APR. > > if I recall correctly multicast support for APR 0.9.x was actually added > thanks to Matt as he implemented it for our tree first because ganglia 2.5.x > supported only multicast (through other means) and a migration to 3.0.x > (which > used APR instead) without it wasn't even a consideration. > > now that 1.2 could be used instead and that doing so was needed for building > a > plugin architecture, the move was a no brainer. > > that doesn't mean though we will left our users needing static builds out in > the cold as we didn't leave our users using multicast either. > >> In addition, I would like to see Gmetad ported on top of APR as well so that > it can take advantage of the portability advantages of APR. I'm not sure > that work going forward would include a static build capability. Certainly > not on APR 0.9.x anyway. > > that could be done in a way that is APR 0.9.x compatible, or we can of > course > update the srclib version to APR 1.2 (or whatever is needed) at that time, > and > keep the static build capability. > > if there is really no compatible way to do that and still keep the static > build > capability then it will be probably better just to drop it and delete at > that > time but since that project wasn't even in the ganglia 3.1.x wishlist I am > assuming it is ganglia 4.x material anyway. > > Carlo > > * I made 1 patch to fix some APR 1.x specific parameters that were > preventing > trunk to build with the included APR 0.9.x, but it only required 5 minutes > when looking at the APR 0.9.x documentation to use instead the backward > compatible ones.
The APR 0.9.x versions were always considered to be beta and these days, it gets very little attention. Not much more attention is paid to Apache 2.0.x. In fact if it wasn't for Jim Jagielski who is about the only one still maintaining the 1.3.x code, all support for Apache 1.3.x would probably have ceased a couple of years ago. I joked with Jim at ApacheCon a couple of weeks ago about where else would you see the chairman of an organization such as the ASF, still coding :) As I mentioned in a previous email, I have no problem leaving the --enable-static-build as long as the user understands what they are getting. There is also the option of statically linking the modules as well, as suggested by Jesse. This will allow for ganglia to be extended at compile time to support more metrics at the expense of flexibility. However, dynamically loadable python modules should still work even in a static build environment, so that might be the answer for getting some of the flexibility back. I think that it would be great if you picked up the maintenance for the 3.0.x branch. While the project is moving forward into 3.1.x, I think it would be nice for those users that can't make the leap yet, to still have an avenue for getting bug fixes and critical patches. This just helps to make the transition smoother. Brad ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
