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. 

> > 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 
consider that your needs and ways of working may not always be the best for 
all situations.  as i mentioned in my previous mail (as well as rasmus in a 
later mail) this type of bundling doesn't scale in an environment where there 
are thousands of other software packages to maintain, and makes life very 
difficult in a "stable release" environment.

jftr, i'm in no way saying what php does with bundling timezone info (or other 
software) is wrong, in fact i think that it's perfectly fine.  but there are 
side effects which are problematic for distributions such as debian and 
redhat and i don't see what's so wrong with trying to address the needs of 
such users (modulo serious regressions/breakage of course).

also jftr i was incorrect in stating that the debian php tz db was ripped out 
of php, it is in fact the pecl module which will be maintained in the 
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 maintaining
> > not just your software but thousands of other projects' packages... 
> > 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.  
that is, it seemed to me most of your rationale against joe's suggestion was 
with "implementation details" which could hopefully be fixed, or with "not 
seeing things from our side", which i also hope can be fixed :)


        sean

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to