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

[Toby Dickenson]

On Monday 16 Sep 2002 1:50 pm, Chris Withers wrote:

> > 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?

A reminder of what you wrote:

+      - Fixed bug in manage_editProperties which used an incorrect defau=
lt
+        for several types of property when they were not found in the
+        REQUEST.

This CHANGES.txt entry for the trunk was fine. For a maintenance release =
I=20
would prefer to see a little more detail. Otherwise it leaves me wonderin=
g:
    a default for what?
    why was it incorrect?
    which properties?
    why is the change safe?
For a maintenance release, the ChangeLog should leave the reader in no do=
ubt=20
that applying the patch is a good thing.

(Please dont take this as a criticism. What you wrote wasnt wrong, or bad=
, or=20
inconsistent with the way previous maintanence release have been=20
documentated. I was taking this opportunity to be picky because I would l=
ike=20
to see this practice improve.)


> > 4. The maintenance release should address stable installations. We sh=
ould
> > exclude fixes for problems that will only be discovered during
> > development.
>
> Don't agree at all. Problems discovered during development may well aff=
ect
> stable installations if only small tweaks are made to those installatio=
ns.

Hmmm, yes. I didnt quite write what I meant to, and I think we agree. Pro=
blems=20
that can affect a stable installation need to be addressed (no matter how=
=20
they are discovered)

I was intending to refer to problems that cant possibly affect a stable=20
installation, but which might limit development of new products. For exam=
ple,=20
a problem that prevents some method being overridden in a subclass.
=20
> In this case, simply unchecked on box on a CMF Type Information Object'=
s
> property sheet would have revealed it.

OK, that is sufficient justification for addressing this problem in a=20
maintenance release.

> > 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 numb=
er
> > of stable installation.
>
> How does 'all people using the CMF' sound?

more than enough.

> > * including the fix will not cause any problems for anyone
>
> Ideally, yes, but I think if after discussion on a -dev list (which I k=
now
> this particular fix wasn't :-S) no-one comments that they're relying on=
 the
> broken behaviour, why wait?

If someone feels that he has to study every proposal on *-dev to ensure t=
hat=20
maintenance releases will not break his applications, then the end result=
=20
will be that people dont apply maintenance release fixes.


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

As David Murray pointed out, this is down to customer education. Wouldnt =
that=20
education process be so much easier if your customers could look at the d=
iff=20
or ChangeLog themselves, and be left with no doubt that we are being care=
ful=20
with their stability?


Chris, youve mentioned before that you use RedHat linux. Do I remember th=
at=20
right? Would these same 'customers' be happy using a RedHat kernel? or wo=
uld=20
they balk at anything other than a pure Linus kernel? If not, why the dua=
l=20
standard between kernels and Zope?