Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34657
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain debian.org from 66.93.22.232 cause and error)
To: Derick Rethans <derick@php.net>
Date: Thu, 10 Jan 2008 17:45:12 +0100
User-Agent: KMail/1.9.7
Cc: PHP Developers Mailing List <internals@lists.php.net>,
 Ilia Alshanetsky <ilia@prohost.org>,
 Joe Orton <jorton@redhat.com>
References: <20080109141541.GA14571@redhat.com> <200801100511.30704.seanius@debian.org> <alpine.DEB.0.98.0801100943560.4679@kossu.ez.no>
In-Reply-To: <alpine.DEB.0.98.0801100943560.4679@kossu.ez.no>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1339467.VX8Do8QtIB";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-ID: <200801101745.21071.seanius@debian.org>
Subject: Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
From: seanius@debian.org (sean finney)

--nextPart1339467.VX8Do8QtIB
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

hi derick,

On Thursday 10 January 2008 09:50:14 am Derick Rethans wrote:
> > Personally I think this patch would be great, and I will recommend it to
> > the other debian php maintainers for review.
>
> Let me just remind you:
> This patch BREAKS functionality.

which of course should be avoided if at all possible.=20

> > It would certainly be a lot better
> > than our current solution, where the timezone db has been ripped out of
> > php and put into a seperate package which is managed outside of the
> > stable release cycle (in the "volatile" release area).
>
> That is a silly approach, when we (the PHP project) already provide a
> way to update this without having to make hacks. Have a look at the PECL
> timezonedb extension.

before off-handedly dismissing others' needs and ways of working please=20
consider that your needs and ways of working may not always be the best for=
=20
all situations.  as i mentioned in my previous mail (as well as rasmus in a=
=20
later mail) this type of bundling doesn't scale in an environment where the=
re=20
are thousands of other software packages to maintain, and makes life very=20
difficult in a "stable release" environment.

jftr, i'm in no way saying what php does with bundling timezone info (or ot=
her=20
software) is wrong, in fact i think that it's perfectly fine.  but there ar=
e=20
side effects which are problematic for distributions such as debian and=20
redhat and i don't see what's so wrong with trying to address the needs of=
=20
such users (modulo serious regressions/breakage of course).

also jftr i was incorrect in stating that the debian php tz db was ripped o=
ut=20
of php, it is in fact the pecl module which will be maintained in the=20
volatile repository.

> > I understand that it may make the job of developing/releasing/supportng
> > easier for you to bundle the timezone db (just like libgd, et c), but
> > please consider the position of those who are responsible for maintaini=
ng
> > not just your software but thousands of other projects' packages...=20
> > wouldn't it be possible to at least make this some kind of compile-time
> > option for those of us who do like the idea?
>
> It has very little to do with maintenance, actually, it is more work for
> us to maintain that extension. But apparently you didn't read my other
> mail or simply chose to ignore it.

actually i did, but i took most of it as orthogonal to the point at hand. =
=20
that is, it seemed to me most of your rationale against joe's suggestion wa=
s=20
with "implementation details" which could hopefully be fixed, or with "not=
=20
seeing things from our side", which i also hope can be fixed :)


	sean

--nextPart1339467.VX8Do8QtIB
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQBHhkuhynjLPm522B0RAozvAJ4gPFDknfypP84CNmWswXAegFc6LwCVFAQd
+inQT6cXd0VzEcLwH9fkrg==
=g0jj
-----END PGP SIGNATURE-----

--nextPart1339467.VX8Do8QtIB--