[php-maint] php 5.3 in sid (was: php 5.3.1 in experimental)

[Ondřej Surý]

On Tue, Jan 12, 2010 at 08:52, Raphael Geissert <geissert at debian.org> wrote:
> 2010/1/12 Ondřej Surý <ondrej at debian.org>:
>> On Tue, Jan 12, 2010 at 08:11, Raphael Geissert <geissert at debian.org> wrote:
>>> 2010/1/11 Ondřej Surý <ondrej at debian.org>:
>>>>
>>>> I am all for it. We just need to cherry-pick all changes made to 5.2.x
>>>> (debian-sid) branch meanwhile, so we don't have regressions.
>>>>
>>>
>>> Ok, since nobody has raised any objection, let's do it.
>>>
>>> TODO:
>>>
>>> * Merge latest .12 commits into -experimental branch
>>>
>>> -> Done on my local repository.
>>
>> Already done that and 5.3.1-2 contains all relevant changes since we
>> split the branch. I did some serious cherry picking yesterday. Sorry,
>> if this breaks your local repository.
>
> I made some other changes to the sid branch, but the commits
> notifications mailing list still requires one to be subscribed to
> allow posting so the notifications were not sent (and I am subscribed,
> but not with this address).

I have noticed and merged your work.

>>> * Shall we enable Enchant?
>>>
>>> -> I'd say yes. I've already done it on my local repository, as a
>>> separate package because it pulls in libenchant, libaspell,
>>> libhunspell, libvoikko, libdbus, glib, etc.
>>
>> Yes, separate package.
>>
>>> * Shall we enable intl?
>>>
>>> -> I'd say yes, but am not sure whether it should be done as a
>>> separate package or not.
>>> Things to take into consideration: it adds a dependency on, at least,
>>> libidna, Conflicts (either at dpkg or extensions manager level -- I'd
>>> prefer to handle it at the latter level) php5-idn. Should probably be
>>> packaged separately.
>>
>> Agree, we should not put too many eggs in one basket. We should rather
>> expect huge amount of bug reports, if they will not come...better for
>> us.
>
> In both cases I meant a separate *binary* package, just like the many
> other extensions.

I know. I am just scared of what will come after we upload 5.3.x to
unstable :-).

>>> * Send "bits from..." mail
>>>
>>> -> To mention:
>>> - Migration to 5.3
>>> - Deprecation of # comments
>>> - short_open_tags (see below)
>>> - switch to extensions manager
>>> - Invite new contributors? help with the BTS would be a good start.
>>> - What else? (I'm surely forgetting something)
>>
>> Switch to automake (>= 1.11)? It can affect packages using php5-dev.
>
> Right, although this should easily be detected by archive-wide rebuilds.


>>> * What to do with short_open_tags?
>>>
>>> -> Status:
>>> - The default value in the code is On, but both the development and
>>> production php.inis default to Off.
>>> - Many php apps in Debian still use short_open_tags.
>>>  + But it can now be enabled at runtime, but still requires reporting
>>> it to the apps that use it.
>>
>> I think we should enable it back. Correct way would be to report
>> "deprecated" warning (DEBUG level) to errorlog and disable it only
>> after some time.
>
> Can you work on a patch to add the E_DEPRECATED warning when a script
> requires short_open_tags?

Done. But it needs recompile of php before I push it to our public repo.

>> What we can do is to add this to NEWS.Debian/README.Debian for squeezy
>> and disable short open tags for squeezy+1.
>
> I'm ok with that as long as a warning is added.

Ondrej
-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/