[logging] 1.1.1 release?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[logging] 1.1.1 release?

Henri Yandell
Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly
ready and just needs to be rolled and voted on.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Dennis Lundberg-2
Henri Yandell wrote:
> Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly
> ready and just needs to be rolled and voted on.
>
> Hen

I've been meaning to do this for a long time. There are a couple of
questions to consider before rolling the release:

1. How should it be built?
Ant, Maven 1 or Maven 2. I've been working on the Maven 2 build and feel
confident about in it now. Was kind of hoping that logging-1.1.1 would
be the first commons release to use Maven 2, but I can be persuaded.

2. If we decide to use Maven 2 we should really change the groupId. This
needs to be carefully thought through.

Anyway, I'm here to assist in any way can, if you want to be release
manager for this.

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

jochen-2
On 3/9/07, Dennis Lundberg <[hidden email]> wrote:

> confident about in it now. Was kind of hoping that logging-1.1.1 would
> be the first commons release to use Maven 2, but I can be persuaded.

Too late, commons-fileupload-1.2 is already out. :-)

--
Emacs 22 will support MacOS and CygWin. It is not yet decided, whether
these will be used to run Emacs or the other way round.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Torsten Curdt
In reply to this post by Dennis Lundberg-2
> I've been meaning to do this for a long time. There are a couple of  
> questions to consider before rolling the release:
>
> 1. How should it be built?
> Ant, Maven 1 or Maven 2. I've been working on the Maven 2 build and  
> feel confident about in it now. Was kind of hoping that  
> logging-1.1.1 would be the first commons release to use Maven 2,  
> but I can be persuaded.

+1 for maven2

> 2. If we decide to use Maven 2 we should really change the groupId.  
> This needs to be carefully thought through.

+1 for changing the groupId

cheers
--
Torsten





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Henri Yandell
In reply to this post by Dennis Lundberg-2
On 3/9/07, Dennis Lundberg <[hidden email]> wrote:

> Henri Yandell wrote:
> > Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly
> > ready and just needs to be rolled and voted on.
> >
> > Hen
>
> I've been meaning to do this for a long time. There are a couple of
> questions to consider before rolling the release:
>
> 1. How should it be built?
> Ant, Maven 1 or Maven 2. I've been working on the Maven 2 build and feel
> confident about in it now. Was kind of hoping that logging-1.1.1 would
> be the first commons release to use Maven 2, but I can be persuaded.
>
> 2. If we decide to use Maven 2 we should really change the groupId. This
> needs to be carefully thought through.
>
> Anyway, I'm here to assist in any way can, if you want to be release
> manager for this.

Definitely happy to give M2 a try; but I'd rather not change the
groupId on a bugfix release. We already have an M2 release in
FileUpload that didn't change the groupid so that's not a worry. Plus
I want to get it done quickly :)

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Torsten Curdt
>
> Definitely happy to give M2 a try; but I'd rather not change the
> groupId on a bugfix release. We already have an M2 release in
> FileUpload that didn't change the groupid so that's not a worry. Plus
> I want to get it done quickly :)

Ah ...my "+1 for changing the groupId" was not meant for this bugfix  
release.
It would be good to change it for new major releases though.

cheers
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Simon Kitching
On Sat, 2007-03-10 at 03:38 +0100, Torsten Curdt wrote:

> >
> > Definitely happy to give M2 a try; but I'd rather not change the
> > groupId on a bugfix release. We already have an M2 release in
> > FileUpload that didn't change the groupid so that's not a worry. Plus
> > I want to get it done quickly :)
>
> Ah ...my "+1 for changing the groupId" was not meant for this bugfix  
> release.
> It would be good to change it for new major releases though.
>

I expect that this will be the last ever release of commons-logging.
There are no features missing, no known bugs, and as support for java
1.4 is now generally universal there is no reason for applications not
to use the java.util.logging API directly.

Note that java.util.logging is an *API*, and the implementation bundled
in Sun's jdk is not the only choice (see JULI for example).

Changing the group-id is something that can only be done on a release,
so it seems sensible to do it for 1.1.1 even if this is just a "bugfix"
release.

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Simon Kitching
In reply to this post by Henri Yandell
On Fri, 2007-03-09 at 17:51 -0800, Henri Yandell wrote:

> On 3/9/07, Dennis Lundberg <[hidden email]> wrote:
> > Henri Yandell wrote:
> > > Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly
> > > ready and just needs to be rolled and voted on.
> > >
> > > Hen
> >
> > I've been meaning to do this for a long time. There are a couple of
> > questions to consider before rolling the release:
> >
> > 1. How should it be built?
> > Ant, Maven 1 or Maven 2. I've been working on the Maven 2 build and feel
> > confident about in it now. Was kind of hoping that logging-1.1.1 would
> > be the first commons release to use Maven 2, but I can be persuaded.
> >
> > 2. If we decide to use Maven 2 we should really change the groupId. This
> > needs to be carefully thought through.
> >
> > Anyway, I'm here to assist in any way can, if you want to be release
> > manager for this.
>
> Definitely happy to give M2 a try; but I'd rather not change the
> groupId on a bugfix release. We already have an M2 release in
> FileUpload that didn't change the groupid so that's not a worry. Plus
> I want to get it done quickly :)

I'm keen to see it built using maven2.

However the problem is that maven2 requires java1.4 to run while we want
the resulting binary to work in java1.2.

Option 1 is for the maven buildfile to ensure that all compilation and
unit tests are done with an external jdk of version 1.2. That's tricky
though.

Option 2 is to build the release with whatever version you want (eg 1.6)
but use target=1.2, then test with 1.2 to ensure that there are no
dependencies on methods not available in earlier jdks. This sounds
better to me. I think it would be possible to create a very simple ant
file that can be run with java 1.2 (on windows probably, as java1.2 is a
pain to install on linux). This ant file would use an existing jar and
precompiled unit tests, and just re-execute those unit tests with the
old jdk. I have been meaning to set this up for a long while now but
just cannot find the time..


Cheers,

Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Wendy Smoak
On 3/9/07, Simon Kitching <[hidden email]> wrote:

> Option 1 is for the maven buildfile to ensure that all compilation and
> unit tests are done with an external jdk of version 1.2. That's tricky
> though.

I researched this question earlier this week.  There are some links on
the compiler plugin wiki page:
http://docs.codehaus.org/display/MAVENUSER/Compiler+Plugin

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Commons Logging deprecated? was Re: [logging] 1.1.1 release?

olegk
In reply to this post by Simon Kitching
On Sat, 2007-03-10 at 16:05 +1300, Simon Kitching wrote:

> On Sat, 2007-03-10 at 03:38 +0100, Torsten Curdt wrote:
> > >
> > > Definitely happy to give M2 a try; but I'd rather not change the
> > > groupId on a bugfix release. We already have an M2 release in
> > > FileUpload that didn't change the groupid so that's not a worry. Plus
> > > I want to get it done quickly :)
> >
> > Ah ...my "+1 for changing the groupId" was not meant for this bugfix  
> > release.
> > It would be good to change it for new major releases though.
> >
>
> I expect that this will be the last ever release of commons-logging.
> There are no features missing, no known bugs, and as support for java
> 1.4 is now generally universal there is no reason for applications not
> to use the java.util.logging API directly.
>

Hi Simon,

This is a little bit of a shocker to me. Does your opinion represent the
collective opinion of the JCL developers? Do I interpret your message
correctly that JCL has been effectively deprecated, there will be no
work done toward JCL 2.0 and the upstream projects that currently depend
on JCL are advised to migrate to JUL?

Cheers,

Oleg

> Note that java.util.logging is an *API*, and the implementation bundled
> in Sun's jdk is not the only choice (see JULI for example).
>
> Changing the group-id is something that can only be done on a release,
> so it seems sensible to do it for 1.1.1 even if this is just a "bugfix"
> release.
>
> Cheers,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Commons Logging deprecated? was Re: [logging] 1.1.1 release?

simon.kitching

---- Oleg Kalnichevski <[hidden email]> wrote:

> On Sat, 2007-03-10 at 16:05 +1300, Simon Kitching wrote:
> > I expect that this will be the last ever release of commons-logging.
> > There are no features missing, no known bugs, and as support for java
> > 1.4 is now generally universal there is no reason for applications not
> > to use the java.util.logging API directly.
> >
>
> This is a little bit of a shocker to me. Does your opinion represent the
> collective opinion of the JCL developers? Do I interpret your message
> correctly that JCL has been effectively deprecated, there will be no
> work done toward JCL 2.0 and the upstream projects that currently depend
> on JCL are advised to migrate to JUL?

It's only my personal opinion. However I am one of the major contributors to JCL since 1.0.4.

There is nothing *wrong* with JCL, and the code isn't going to be removed from the Apache servers. And if there are any significant bugs found they are likely to be fixed. So there's no need to be worried, or to rush off to change any existing code.

However if code requires java1.4 or later for other reasons I don't see any benefit in that code using JCL; the java.util.logging api is built in to java so why download an additional jar?

For libraries that still want to support java1.3 or older, JCL is an excellent choice. However that's a rapidly shrinking category. Apache Tomcat now requires java1.4, and has moved to java.util.logging as its API (with JULI as the underlying implementation); I would suggest other code do the same.

I did spend some time and effort researching possible "JCL 2.0" designs, but after further thought decided there was little point. Of course I'm only speaking for myself here.

Regards,

Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Henri Yandell
In reply to this post by Simon Kitching
On 3/9/07, Simon Kitching <[hidden email]> wrote:

> On Fri, 2007-03-09 at 17:51 -0800, Henri Yandell wrote:
> > On 3/9/07, Dennis Lundberg <[hidden email]> wrote:
> > > Henri Yandell wrote:
> > > > Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly
> > > > ready and just needs to be rolled and voted on.
> > > >
> > > > Hen
> > >
> > > I've been meaning to do this for a long time. There are a couple of
> > > questions to consider before rolling the release:
> > >
> > > 1. How should it be built?
> > > Ant, Maven 1 or Maven 2. I've been working on the Maven 2 build and feel
> > > confident about in it now. Was kind of hoping that logging-1.1.1 would
> > > be the first commons release to use Maven 2, but I can be persuaded.
> > >
> > > 2. If we decide to use Maven 2 we should really change the groupId. This
> > > needs to be carefully thought through.
> > >
> > > Anyway, I'm here to assist in any way can, if you want to be release
> > > manager for this.
> >
> > Definitely happy to give M2 a try; but I'd rather not change the
> > groupId on a bugfix release. We already have an M2 release in
> > FileUpload that didn't change the groupid so that's not a worry. Plus
> > I want to get it done quickly :)
>
> I'm keen to see it built using maven2.
>
> However the problem is that maven2 requires java1.4 to run while we want
> the resulting binary to work in java1.2.

Given this, and your view that little change is needed in the future
for JCL I don't see any reason to spend lots of effort on the build
system when the previous build style could be used (ie: Ant). I've
previously had pain trying to get a running java1.2 system and have
built under java1.3, but I could give 1.2 another try.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Julius Davies
Hi,

I've had the same problem.  I *cannot* get 1.2 running on linux anymore.

I hate to say it.... but the only way I can get 1.2 going these days
is by installing it on Windows.  Installs really nicely, to tell the
truth.

yours,

Julius


>
> Given this, and your view that little change is needed in the future
> for JCL I don't see any reason to spend lots of effort on the build
> system when the previous build style could be used (ie: Ant). I've
> previously had pain trying to get a running java1.2 system and have
> built under java1.3, but I could give 1.2 another try.
>
> Hen


--
yours,

Julius Davies
416-652-0183
http://juliusdavies.ca/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Patch for Logging 1.1 to run in applets.

Pavel Vlasov
Hello,

Today I tried to use HttpClient from an applet and I run into a quite a
number of problems with commons logging version 1.1. Searching internet and
Commons Wiki didn't yield any valuable result.

Thus, I had to modify LogFactory.java around line 320, I added a catch block
for SecurityException, which was missing. Please find code below:

        String storeImplementationClass;
        try {
        storeImplementationClass =
System.getProperty(HASHTABLE_IMPLEMENTATION_PROPERTY);
        } catch (SecurityException e) {
        storeImplementationClass = null;
        }

Also I had to create my own implementation of LogFactory because default
implementation invokes getClasLoader() method, which is prohibited in
Applets.

Here is the no-op implementation:

public class NoOpLogFactory extends LogFactory {
       
        private Log log = new NoOpLog();
       
        private Map attributes = new HashMap();

        public Object getAttribute(String name) {
                return attributes.get(name);
        }

        public String[] getAttributeNames() {
                return (String[]) new
ArrayList(attributes.keySet()).toArray(new String[attributes.size()]);
        }

        public Log getInstance(Class clazz) throws LogConfigurationException
{
                return log;
        }

        public Log getInstance(String name) throws LogConfigurationException
{
                return log;
        }

        public void release() {
                // Nothing to release
        }

        public void removeAttribute(String name) {
                attributes.remove(name);
        }

        public void setAttribute(String name, Object value) {
                attributes.put(name, value);
        }

}

I've installed it by specifying class name in a configuration file in
META-INF/services in one of my jars

Please review these changes and incorporate into the library if appropriate.
Also please let me know if there is another way to make commons logging work
in applets.
---
Best regards, Pavel.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Patch for Logging 1.1 to run in applets.

Dennis Lundberg-2
The upcoming 1.1.1 release has fixed these issues.

Pavel Vlasov wrote:

> Hello,
>
> Today I tried to use HttpClient from an applet and I run into a quite a
> number of problems with commons logging version 1.1. Searching internet and
> Commons Wiki didn't yield any valuable result.
>
> Thus, I had to modify LogFactory.java around line 320, I added a catch block
> for SecurityException, which was missing. Please find code below:
>
>         String storeImplementationClass;
>         try {
>         storeImplementationClass =
> System.getProperty(HASHTABLE_IMPLEMENTATION_PROPERTY);
>         } catch (SecurityException e) {
>         storeImplementationClass = null;
>         }
>
> Also I had to create my own implementation of LogFactory because default
> implementation invokes getClasLoader() method, which is prohibited in
> Applets.
>
> Here is the no-op implementation:
>
> public class NoOpLogFactory extends LogFactory {
>
> private Log log = new NoOpLog();
>
> private Map attributes = new HashMap();
>
> public Object getAttribute(String name) {
> return attributes.get(name);
> }
>
> public String[] getAttributeNames() {
> return (String[]) new
> ArrayList(attributes.keySet()).toArray(new String[attributes.size()]);
> }
>
> public Log getInstance(Class clazz) throws LogConfigurationException
> {
> return log;
> }
>
> public Log getInstance(String name) throws LogConfigurationException
> {
> return log;
> }
>
> public void release() {
> // Nothing to release
> }
>
> public void removeAttribute(String name) {
> attributes.remove(name);
> }
>
> public void setAttribute(String name, Object value) {
> attributes.put(name, value);
> }
>
> }
>
> I've installed it by specifying class name in a configuration file in
> META-INF/services in one of my jars
>
> Please review these changes and incorporate into the library if appropriate.
> Also please let me know if there is another way to make commons logging work
> in applets.
> ---
> Best regards, Pavel.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Henri Yandell
In reply to this post by Julius Davies
On 3/12/07, Julius Davies <[hidden email]> wrote:
> Hi,
>
> I've had the same problem.  I *cannot* get 1.2 running on linux anymore.
>
> I hate to say it.... but the only way I can get 1.2 going these days
> is by installing it on Windows.  Installs really nicely, to tell the
> truth.

Yup. I hear you can patch your glibc on Linux, but I went with Windows
for 1.2. Except I decided to be clever and install all versions on
there and that screwed things up for some reason (1.6 was being too
smart). Seems to work now though, so I can wince and do a build on
Windows.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

simon.kitching
In reply to this post by Henri Yandell

---- Henri Yandell <[hidden email]> wrote:

> On 3/9/07, Simon Kitching <[hidden email]> wrote:
> > On Fri, 2007-03-09 at 17:51 -0800, Henri Yandell wrote:
> > > On 3/9/07, Dennis Lundberg <[hidden email]> wrote:
> > > > Henri Yandell wrote:
> > > > > Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly
> > > > > ready and just needs to be rolled and voted on.
> > > > >
> > > > > Hen
> > > >
> > > > I've been meaning to do this for a long time. There are a couple of
> > > > questions to consider before rolling the release:
> > > >
> > > > 1. How should it be built?
> > > > Ant, Maven 1 or Maven 2. I've been working on the Maven 2 build and feel
> > > > confident about in it now. Was kind of hoping that logging-1.1.1 would
> > > > be the first commons release to use Maven 2, but I can be persuaded.
> > > >
> > > > 2. If we decide to use Maven 2 we should really change the groupId. This
> > > > needs to be carefully thought through.
> > > >
> > > > Anyway, I'm here to assist in any way can, if you want to be release
> > > > manager for this.
> > >
> > > Definitely happy to give M2 a try; but I'd rather not change the
> > > groupId on a bugfix release. We already have an M2 release in
> > > FileUpload that didn't change the groupid so that's not a worry. Plus
> > > I want to get it done quickly :)
> >
> > I'm keen to see it built using maven2.
> >
> > However the problem is that maven2 requires java1.4 to run while we want
> > the resulting binary to work in java1.2.
>
> Given this, and your view that little change is needed in the future
> for JCL I don't see any reason to spend lots of effort on the build
> system when the previous build style could be used (ie: Ant). I've
> previously had pain trying to get a running java1.2 system and have
> built under java1.3, but I could give 1.2 another try.


The "previous build style" was very manual. The old ant files do build a valid JCL jar, but were *not* used as-is to generate previous official releases. One issue is that the java.util.logging adapters must of course be compiled with java1.4 or later, but other code needs to be compiled using 1.2 (or at least tested with that version). So bits of the code were compiled with different java versions and the results stitched together by hand; I believe Robert Donkin documented this somewhere. I do remember it was a scary process.

The maven-2 build stuff is all done and verified. All that is needed is some way of testing the final binary output under java 1.2, and I think this is a much saner way to tackle a release.

Cheers,

Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Henri Yandell
On 3/12/07, [hidden email] <[hidden email]> wrote:

> The "previous build style" was very manual. The old ant files do build a valid JCL jar, but were
> *not* used as-is to generate previous official releases. One issue is that the java.util.logging
> adapters must of course be compiled with java1.4 or later, but other code needs to be compiled
> using 1.2 (or at least tested with that version). So bits of the code were compiled with different
> java versions and the results stitched together by hand; I believe Robert Donkin documented
> this somewhere. I do remember it was a scary process.
>
> The maven-2 build stuff is all done and verified. All that is needed is some way of testing the final > > binary output under java 1.2, and I think this is a much saner way to tackle a release.

Which tests need to be run under 1.2? All of them?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

sebb-2-2
In reply to this post by Henri Yandell
On 13/03/07, Henri Yandell <[hidden email]> wrote:

> On 3/12/07, Julius Davies <[hidden email]> wrote:
> > Hi,
> >
> > I've had the same problem.  I *cannot* get 1.2 running on linux anymore.
> >
> > I hate to say it.... but the only way I can get 1.2 going these days
> > is by installing it on Windows.  Installs really nicely, to tell the
> > truth.
>
> Yup. I hear you can patch your glibc on Linux, but I went with Windows
> for 1.2. Except I decided to be clever and install all versions on
> there and that screwed things up for some reason (1.6 was being too
> smart). Seems to work now though, so I can wince and do a build on
> Windows.
>

The install process puts a copy of java.exe (and javaw.exe) in
windows\system32 which can appear earlier in the classpath than your
desired Java directory ...

==

I find it useful to define variables for each of the installed Javas(eg):

JAVA142_HOME=C:\j2sdk1.4.2_13
JAVA150_HOME=C:\jdk1.5.0_11
JAVA160_HOME=C:\jdk1.6.0

I can then define JAVA_HOME as one of those, and add JAVA_HOME\bin to the path.

I've got some JAVAxxx.CMD files that I use in DOS boxes to set the
appropriate version - you're welcome to a copy, just let me know.

S.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] 1.1.1 release?

Henri Yandell
In reply to this post by Henri Yandell
On 3/9/07, Henri Yandell <[hidden email]> wrote:
> Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly
> ready and just needs to be rolled and voted on.

Rescinding this - doesn't look like it's ready in that there's gubbins
to do for the build and I'm not clueful on the things needing doing.

ie) it became a pain in the arse to contemplate :)

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]