On Thu, Mar 4, 2010 at 2:37 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Thu, Mar 4, 2010 at 2:42 AM, Fabio Tranchitella <kobold@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