[Zope-dev] Uses of the ZTK and how it relates to management

[Jim Fulton]

On Thu, Mar 4, 2010 at 2:37 PM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jim Fulton wrote:
>
>> On Thu, Mar 4, 2010 at 2:42 AM, Fabio Tranchitella <kobold at kobold.it> wrote:
>>> * 2010-03-03 21:44, Jim Fulton wrote:
>>>> The ZTK was created in part to deal with instability issues arising from
>>>> people working on parts without testing the whole.
>>> I suppose everybody here agrees that any change to a package which is part
>>> of the ZTK *must* be tested against the whole ZTK.
>>
>> It would be great if that were true.  If so, then the recent arguments
>> have been a terrible misunderstanding.
>
> I think that most of the misunderstanding lies in the nature of
> "ownership" of the packages in the ZTK:  some would like everyone to
> care equally about all the packages (including those now factored into
> the zopeapp.cfg set), while others want to give most of their attention
> to some smaller set of packages which they use every day.  We already
> have some policies in place which recognize that the "bicycle seat
> toolkit" packages need special handling, becaues they are used outside
> the Zope ecosystem (one rule is that we attempt to keep Python 2.4
> compatibiltiy for those packages).
>
> I certainly don't think anybody here would argue against having the big
> 'compattest' tests get run:  even the "splitters" and "whittlers" (I
> might be called one of those) are willing to help fix things when a
> change to one package breaks the others.  If we could get automated
> testing of the various compatibility sets established, with automated
> reporting of failures, I think we would see a huge improvement in the
> signal here:  instead of arguing hypotheticals, we would be focused on
> fixing "real" breakages.

+1

Hopefully the discussions about buildbots will bear fruit.

>>> It would be easier to
>>> find leading developers for subgroups of packages (eg. bicycle repair kit,
>>> rm generation, ...) willing to raise the quality of a specific subset of
>>> packages instead of finding a release manager willing to oversee > 60
>>> packages, which he does not really use (because I don't think we have a
>>> single developer using *all* of the packages in the ZTK).
>>>
>>> These specific leading developers could report and synchronize with a ZTK
>>> release manager, though.
>>
>> There's nothing preventing people from doing this AFAICT.  If someone
>> is interested in pursuing a change to a package or collection of
>> packages, they can do so with or without some organizational
>> structure.  Problems would arise only if they proposed a backward
>> incompatible change, which isn't to say that backward-incompatible
>> changes are impossible.
>
> We still mostly treat them as off-limits, even the three years after we
> started the effort to break the monolith apart.  That change should have
> made it technically feasible to do backward-incompatible changes, but we
> haven't yet worked out how to make that happen.

I wonder how many situations there are where backward incompatible
changes are needed to unblock other work.  I don't suppose we have a
list of these do we?

One thing that makes problems like this really hard is that email is such
a terrible tool for much of the needed communication.  It would be nice
if we could do something more sprinty.  I don't want to help if it involves
drawn out email discussions, but, FWIW, I'd be willing to allocate some
concentrated blocks of time for high-bandwidth discussion and work.

Jim

-- 
Jim Fulton