[dev] CSS Parsing class

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Rui Carneiro <rui.carneiro at portugalmail.net>:
>>>
>>>> *Original:*
>>>> 1- box-shadow:0 3px 4px rgba(0,0,0,0.4);
>>>> 2- opacity:0.7;
>>>> 3- line-height:1.2em;
>>>> 4-
>>>> filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#f4f4f6',endColorstr='#e1e2e5',GradientType=0);
>>>> 5- margin: 23px 3px 0 8px;
>>>
>>> It looks like there is an issue with locale conversions.  Not a  
>>> big deal.  Can probbably be fixed in a few seconds.  Guessing it's  
>>> an issue with a floatval() call not being made locale independent.
>>
>> In my opinion, it's irrelevant if *this* issue is something that  
>> can be fixed in a few seconds. This demonstrates the root of the  
>> issue. There was a negative change in behavior due to the new  
>> library that we did not foresee. This is why entire libraries  
>> should *never* be changed in bugfix releases. It's simply just too  
>> large of a change in the code base. It's not about the number of  
>> loc that were changed, it's about *what* code was changed. It's a  
>> completely new library that has not gone through the normal beta  
>> test cycle that a minor or major release would go through before  
>> being declared stable.
>
> But the original library is broken and CANNOT be fixed (at least  
> without rewriting that entire library).  You cannot ignore that.

We didn't. And you cannot ignore Michael's argument either. These are  
exactly the things that can happen if you replace such large amounts  
of code in a bug fix release, despite all of the local testing. That's  
why we have beta versions.
The old library might be broken, and definitely needs replacement. But  
in some cases it's really better to leave a known bug unfixed and keep  
the fixing for a future release that gets more testing.

> Saying we need to leave the original BROKEN code in place because  
> that's the status quo is absolutely absurd!  By that reasoning we  
> should never fix bugs because it might break current behavior. (Sure  
> enough, the code implemented to fix logging appears to be causing  
> some unwanted behavior for new people.  But does that mean we should  
> have not implemented the original bug fix?  Of course not.)

That's why I suggested a compromise approach that allows to run both  
compressors. Keep the old one in place for people that are happy with  
it, or that experience problems with the new compressor, so that they  
can switch back easily. And provide the new compressor for people who  
*do* experience problems with the old one, and get some production  
testing in real-life setups until it is stable to be the single  
compressor for Horde 5.1.

> If a bug fix causes another bug fix, you fix the new bug fix.   
> That's the way ANY bug fix works.  Theoretically we release the new  
> code, someone reports a bug, we release a new package immediately.   
> We are still in better position than we were with the old broken code.
>
> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]


-- 
Jan Schneider
The Horde Project
http://www.horde.org/