I didn't closely follow the earlier discussions about including APC, but I
(and at least some other people working a lot on Drupal) had been mostly
assuming it'd be included in 5.4 based on those.
The assumption that APC is available by default (if not necessarily enabled)
would allow us to start
Unless test failures are critical, it seems worth either commenting out or
converting to xfail ones that can't be immediately fixed.
That gives a 0 fail baseline to work from for detecting regressions, and
test failures should be associated with bug reports anyway so it's not like
they'd get lost
From my phone. Apologies for brevity and typos.
On 2011/08/20, at 9:03, Rasmus Lerdorf wrote:
>>
>>
>
> The secondary problem is that we are not doing a good job running our
> tests prior to releases. I think this is mostly because we have way
> too
> many tests that fail and one more or less
fwiw with Drupal we have a central repository for the core and contributed
projects hosted on Drupal.org. There are also sandbox projects (which can be
either experimental new projects or forks), and these are also centrally
hosted.
This doesn't stop people using github, but it massively increased
>
>
>>
> As far as I can see this is for built-in functions only. The problem I see
> is, that APC cannot know, where my functions are located and therefore
> cannot load it without userspace help.
>
>
>
No it includes userspace functions. My knowledge of APC internals is very
weak, but more or les
There is lazy loading for functions via apc.lazy_functions (although I've
not properly tested this yet). That doesn't require any userspace code
changes.
For define() I'm not aware of anything allowing for lazy loading constants
(define() is just a function call).
However there are a few approach
