On Thu, Mar 4, 2010 at 2:37 PM, Tres Seaver <tsea...@palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Jim Fulton wrote:
>> On Thu, Mar 4, 2010 at 2:42 AM, Fabio Tranchitella <kob...@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.
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -