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.
+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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
