Hi all!

Ken Causey ken@kencausey.com wrote:

On Tue, 2005-06-21 at 15:00 +0200, goran@krampe.se wrote:

...

Ken asked "What are we waiting for?" and... I am not sure. The PI-partitioning bit - which is key here - should simply "be done" IMHO. I say let's get *a single person* to just do it and push a .cs into the stream which creates the PIs. I was inclined to get Doug to do it (being v3.9 boss and all), but I don't really care as long as someone does it. Again, I am not sure how this plays with the latest plans/developments (read the packages archive for details).

In case you don't know the message from me that Goran is referring to is at

http://discuss.squeakfoundation.org/cgi-bin/ezmlm-cgi?8:msp:221:ooeonbbmifc= eghgaabgc

I'm assuming you (Goran) mean that 'PI-partitioning' is 'key' to allowing developers to take responsibility for parts of this system but I don't think that is true. Even if we stepped back a bit to a monolithic image with a single update stream there is no technological barrier to staking out the bits in the image and having people sign up and take responsibility for them. I'm not saying it is perfect but there is absolutely no reason I can see that the existing partitioning into the current categories and classes isn't sufficient. Clearly there would not be a mapping of one category to one team in every or even most cases and in some cases it may even be desirable to split a single category between two teams, but I don't see a big problem with that. Of course it may be the case that two teams are working on highly inter-related parts of the system in which case their will need to be good communication between them, but I think that will be true in any partitioning system.

I think we agree - when I say "PI-partitioning" I don't mean refactoring or recategorization. I am all for the simplest thing - just assigning 1-n categories to one PI (almost, see below).

Each team would then either be given direct access to the update stream or perhaps more realistically in the short term they would send their changesets to the Coordinators or other small group that has direct access to the update stream. It would be understood that the team is responsible for what enters the update stream and would be expected to take care that it is likely to be acceptable to the community as a whole. The 'update stream team' then would not be expected to do much if any checking of what was submitted only probably keeping track of what update came from which team and when.=20

Yes, and this is exactly what I was after earlier in TFNR - the idea that you don't need to "split out" packages in order to take responsibility for them - the update stream can work just fine.

In some cases a change to one team's part of the system will affect one or more other teams. It should be clear to all teams that this is one of the things they will need to consider and that it is up to them to coordinate with the other teams and to see that the other teams understand what needs to be done and are aided in doing that and seeing that their changes enter the update stream roughly in sync with the first team's.

Admittedly this, at least until teams have matured somewhat, will likely result in a more chaotic update stream. But I believe that it can be managed and that in any case any other partitioning scheme that I can see appearing in the near future is almost certainly going to have the same issues.

Now let me be clear that I am not by any means against the pursuit of other and better systems. Please keep working on this. However it's clear that producing a better system is not simple and is taking time. Can we afford to stall basic development while we wait? I don't see any reason why we can't get started with what we have and transition to a better system when it becomes available.

Again, let me explain what *I* meant us to do - I think you and I are all in agreement.

1. A single person sits down and groups the categories into PIs. The current categories are probably just fine, and if that person feels like it he may of course move classes around or rename categories - but *nothing else*. And he mustn't get stuck. The result: A .cs that performs the recategorizations/moves and creates PI instances in the image according to the grouping.

2. Someone (say me) creates packages on SM for each such PI and types the PI name into the field for that. Then we assign the SM packages to an owner and add co-maintainers to that. Tada - we then have our teams with names, emails etc. all neatly described in SM and thus in easy reach for tools.

3. We start by what you describe above - just use the update stream as before. No problem.

Ok, now - the above is actually one days work if we just decided to "do it". But there is now a different plan on the playfield - to go with what Impara is doing. Avi is Team leader. I trust him to help us come to a decision on what to do.

regards, Göran