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

[Tres Seaver]

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

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



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuQC9gACgkQ+gerLs4ltQ4x8QCfXQ2JkuCy4XyJgHDuzrZZjLIc
1wkAn0J7kdM4F4iRcO4OP2EGGsKi+1vB
=r+V4
-----END PGP SIGNATURE-----