[PHP-INTERNALS] 5.3 release schedule and other bits

Awesome, does that also mean you'd be willing to listen in case we might
think some patches are a bad idea?

regards,
Derick

Yes, I've seen the RCs. Hope it doesn't take long.
Yes, I'm willing to discuss patches.

Cheers,

Great news!
Does it mean, that 5.3 will move to "unstable" branch soon?
(currently, Debian has 5.3 only in "testing")

the path is like unstable -> testing -> stable
so the testing will be the new stable.
http://en.wikipedia.org/wiki/File:Debian-package-cycle.png

Tyrael

It is currently in "experimental," but yes, we will soon be uploading it to
unstable so that it later migrates to testing.

Cheers,

Wouldn't we all. Haven't seen any merges to the release branch since it
was created..apart from some useless copyright year update.

Johannes, wake up already and start doing what the RM is supposed to do:
RELEASE something. And discuss the matters related to releases on
internals@ and ONLY on internals@ mailing list.

--Jani

Hi,
I hope that the new release branch mere-tracking-tool goes live today,
so that the new experimental release branch based process works nicer,
so 5.3.2RC2 will follow shortly after (either until tomorrow, which will
be quite a rush, better tuesday next week) further progress then depends
on feedback from testers, hopefully 5.3.2 will be out very late
January/early February.
for 5.3.3 it depends on security issues being reported, bug fixes going
in, ... maybe 3 months after.
I think that's an important topic. And I think it would be good to
improve communication with packagers to unify things that might be
handled differently and prevent packagers from back-porting security
fixes in a wrong way. I now that MySQL has a "packgers" list, maybe such
a thing might be good for php, too. internals might sometimes be a bit
crowded to follow ...

johannes

Ok, so it looks we will be releasing with 5.3.2 + any backported patch
necessary to fix important or critical bugs. Thanks for the info.
Such kind of mailing list might be useful, yes. It would at least help give
the impression that there's interest on improving the communication
channels.
That said, I think reading and at times discussing stuff here will still be
needed.
As for security patches, yes, it would help if for every issue there's a
pointer to the commits fixing them. I recently started a discussion on oss-
sec about PHP's security policy, but haven't brought it up with the php
security team yet.

I hope we can make a progress.

Cheers,

Hi Johannes,

Johannes Schlüter wrote:
With the current discussion about moving 6.0 to a branch and continuing the
development of 5.4+ in trunk, I was wondering if there is going to be a
change of plan.

I'm mostly interested in knowing if it would be possible to get 5.3.3 out in
a month, more or less (the latter preferred). This would be of great help
from a Debian POV, as it would reduce the divergence; otherwise at Debian we
are going to end up with 5.3.2 with many patches (probably more than those
we included in 5.2.6 for lenny, because of our current work to get the
testsuite to pass).

Cheers,

Also, Mac users have the same desire. A recent bug fix makes compiling PHP 5.3 on Mac much easier.

Regards,
Philip

Hi Raphael:
Is there a document somewhere that explains the changes the Debian team
has made? (Other than reading a 600 kb diff file from the package web
page.)

Thanks,

--Dan

What patch do you want to know more about?

Patches have not been properly documented, but they are usually referenced
by an entry on the changelog giving a bit more information.

You can browse the patches applied to every release (and download or view
them individually) at:
http://patch-tracker.debian.org/package/php5

Cheers,

None. I am wondering if there is a resource for lay-people interested in
installing PHP via packages so they can know any eccentricities they will
encounter when compared to compiling it themselves.

For example, you discussed changing some ini settings and the possibility
of making short tags throw deprecated warnings. So I wouldn't be
surprised if there are other changes in your forks.

Such a document could also be used to clarify/direct your discussions
here.

This is a little nicer than reading the whole diff file, but as you
mentioned, it still isn't documented well. Meaning it doesn't say
whether a patch is Debian specific or just bringing in something done by
the PHP team itself.

Thanks,

--Dan

Well, there are multiple packages to make php use the system copies of the
libraries and security enhancements, among many other reasons.
The change on the ini file is to avoid breaking applications (that
incorrectly rely on short_open_tag being On) on upgrade (which is very
important). We aren't doing anything really different, the default value in
the interpreter is still On.

The warning was being proposed to make sure those applications are fixed to
avoid having to carry the ini patch too long.
The documentation will be included in the patch header. Note that most of
them predate the time I joined the maintenance team.

Only the debian-quirks and php.ini_securitynotes patches are really Debian-
specific. The rest should find its way to the upstream code (but some of the
patches were not accepted in the past).

Cheers,

It's worth noting that PHP (as of 5.3) does not distribute a php.ini file that contains default values (like php.ini-dist essentially did). So I imagine issues arise when distributions want to enable one during the PHP install.

Curious, do you enable one of the php.ini-* files by default? Which? Perhaps with a few other changed values to meet the defaults, like with short_open_tag?

Regards,
Philip

On 5.2 and older we use -dist. On 5.3 we will take -production as a base but
we have not yet decided what other changes we are going to make.

Cheers,

Each distribution can definitely apply different patches, but in the
case of at least one, improper application or "adjustement" of the patch
can lead to security holes by itself.