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

[Christian Theune]

Hi,

On 03/04/2010 10:44 PM, Jim Fulton wrote:
> On Thu, Mar 4, 2010 at 2:37 PM, Tres Seaver <tseaver at palladion.com> wrote:

Weird. Tres' mail didn't make it into gmane ... I'll fold my replies to
Jim and Tres into this one mail. (Looks like I'm now turning into the
one making noise here. I'm already sorry for people having to read so
much. :) )

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

Something that appeared to me while reading that: the specific set that
a single developer cares for varies over time.

Independent of the specific set I care for at any point in time, I still
am interested in a healthy larger set because I might need that again
tomorrow or next week.

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

Working on that. :)

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

Here's a "save the date": gocept is organising a summit/sprint close to
this year's DZUG conference which will also have sprinting time and
space all over. So that's definitely high-bandwidth. :)

The summit itself will be more oriented to getting the Zope developer
group organies so we can have less of the meta discussions on the
mailing list (that would probably be the part Jim is uninterested in
;)). I'd like to keep that focused on a single day though and use the
rest of the sprinting time for getting stuff done.

So, anyway, here's the dates:

13. September 2010: zope-dev summit in Halle (Saale), Germany
14. September 2010: sprint in Halle (Saale)
15.-17. September 2010: DZUG conference in Dresden, Geramny
18.-19. September 2010: post-conference sprinting days in Dresden

I'd love to see as many of you zope-dev guys here in our offices. :)

Christian

-- 
Christian Theune · ct at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development