[Zope-Coders] Re: [Zope-Checkins] CVS: Zope/lib/python/ZPublisher - Converters.py:1.14.8.2

[Chris Withers]

(comments as requested ;-)

Toby Dickenson wrote:
> 
> 1. Changes shouldnt go onto a maintenance branch without reaching a concensus 
> on zope-dev. Even the 'latest cvs' on the maintenance branch should be free 
> of suprises.

Agreed.

> 2. The ChangeLog should include a rationale for the change, not just a 
> statement about what has changed. We need this to give people who are 
> installing the maintenance release confidence that we are taking care of 
> their stability.

Hmmm... I had the impression my comments in CHANGES.TXT did this, what shoudl I 
have done differently?

> 3. Things on a maintenance branch should be arranged to minimise the size of 
> the diff. Your patch also tidied up indentation - that just makes the hotfix 
> (ahem, maintenance release) seem more intrusive than it really is. It also 
> makes it a fraction harder for anyone wanting to verify for themselves that 
> the release is risk-free before installing it.

Don't really agree. Get a decent diff implementation ;-)

> 4. The maintenance release should address stable installations. We should 
> exclude fixes for problems that will only be discovered during development.

Don't agree at all. Problems discovered during development may well affect 
stable installations if only small tweaks are made to those installations. In 
this case, simply unchecked on box on a CMF Type Information Object's property 
sheet would have revealed it.

>>Only if they relied on this obscure and broken behaviour, which I would be
>>really suprised to hear of :-S
> 
> That reasoning is sufficient to get the change into 2.6, even at this late 
> stage. To get into a maintenance release we need to know that:
> * not including the change will cause problems for a significant number of 
>   stable installation.

How does 'all people using the CMF' sound?

> * including the fix will not cause any problems for anyone

Ideally, yes, but I think if after discussion on a -dev list (which I know this 
particular fix wasn't :-S) no-one comments that they're relying on the broken 
behaviour, why wait?

>>(The other option is to remember to keep patching Zope until I have a
>>compelling reason to move to 2.6.x :-S)
> 
> I think this would be the right option for this patch. It is easily done if 
> you keep your change in a branch, and write a script to use in place of 'cvs 
> update' to merge in all your favorite patches.
> 
> I cant remember the last time I ran a standard version of Zope. Its no big 
> deal.

To answer a question you asked in another thread, you are most definitely 
exceptional in that you're happy to patch software in the way you appear to ;-)

Even if I was, many 'customers' are only happy with official releases and may 
even baulk at security hotfixes being applied.

cheers,

Chris