> BTW, I would be busy starting early Friday afternoon, so if possible,
> could you tag 3.1.3 early Friday? BTW, what timezone are we talking
> about ;-)
>
>
Ok, I will aim for some time between 10:00 and 14:00 British Summer Time
(BST)
---
Hi all:
Sounds good. After you tag it, I believe the process is to generate
the tarball and put it up in the website's beta area, and have people
test it.
After the release is marked as GA, then we can create a release in
SourceForge and upload the files there. I could handle all that.
BTW, I
>>> On 9/16/2009 at 8:26 AM, in message <4ab0f594.4050...@pocock.com.au>, Daniel
Pocock wrote:
>
> As discussed a few weeks back, I'm volunteering to manage the 3.1.3 release.
>
> Most of the changes were made a few weeks ago now, and I've been running
> some of these patches on several platfo
As discussed a few weeks back, I'm volunteering to manage the 3.1.3 release.
Most of the changes were made a few weeks ago now, and I've been running
some of these patches on several platforms for some time, so I don't
think we need to allow a lot of time for additional testing. What I'd
pro
>>> On 9/16/2009 at 8:03 AM, in message <4ab0f04c.9060...@pocock.com.au>, Daniel
Pocock wrote:
>
> I notice in gmetad/Makefile.am that AM_CFLAGS includes -O0
>
> This is the case for both 3.1 and trunk.
>
> Is this intended for some reason? I've looked through the SVN history,
> I can see th
I notice in gmetad/Makefile.am that AM_CFLAGS includes -O0
This is the case for both 3.1 and trunk.
Is this intended for some reason? I've looked through the SVN history,
I can see that it has always been this way since AM_CFLAGS was added to
Makefile.am in r384
It refuses to build on Solar
On Wed, Sep 16, 2009 at 08:41:29AM -0400, Daniel Pocock wrote:
> I'm a little surprised that we have to check the existence of the
> variable every time it is used - I looked at index.php and graph.php,
> and both of them appear to read eval_config.php before reading functions.php
I agree. Ther
Jesse Becker wrote:
> On Thu, Sep 10, 2009 at 13:28, Daniel Pocock wrote:
>
> The reason I didn't put $rrd_options in conf.php is because it's value
> is meant to be derived from other variables, in other words, the
> administrator should not change $rrd_options itself.
>
>
