On Tuesday, October 10, 2000 8:03 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]]
wrote:
> I think we're talking about two different periods of development here.
>
> The immediate question facing us is how to structure software design.
> This is different from the ongoing maintenance of Perl.
>
> We want and need a small group to design perl6 correctly. I can't see
> this working any other way. Software design is a completely different
> process from maintenance, and it's unrealistic to expect the
> maintenance model (big open mailing lists, everyone says what they
> want) to work for an intently cerebral activity.
>
> Design I'm seeing as in two parts: architecture (what are the major
> components we need?) and detailed design (where each component has
> an API designed and the interactions between components resolved).
> The architecture will be partially decided by Larry, and seems best
> done by a few experienced with such things. Detailed design seems
> appropriate for groups of 5-10 people in each area. In both cases,
> public viewing of the proceedings is mandatory (you can read their
> messages and see their thoughts and comment in private).
>
> Implementation is different from design, and different again from
> maintenance. If we do the design, test cases, and stubbing well
> enough, we could have a cast of thousands doing the implementation.
>
> I honestly don't see us arguing over design. Or even over
> implementation. The big meat of this discussion so far seems to have
> been how to prevent the ongoing maintenance of Perl from being
> coopted.
>
> I'm thinking about a team structure for ongoing maintenance. Each
> area (docs, stdlib, interpreter, compiler) has its own team. A team
> is only a few people: the person responsible for submitting patches,
> someone responsible for keeping on top of user demands, and someone
> from QA. In some cases these roles might be shared, and there's no
> law that says the same QA person couldn't be on several teams. The
> only law I'd want is that no team could be made up of people from
> the same company.
>
> In addition to these people is a release manager, coordinating with
> everyone to set realistic deadlines and ensure everyone's talking with
> everyone else. No release goes out the door until all the teams agree
> that they have a Good Enough product. This way neither ActiveState,
> Microsoft, nor the Trilateral Commission can dictate an unrealistic
> release date. And this goes both ways: if there is a dodgy release,
> the blame can't be pointed at just one company. At a team perhaps,
> but there can be no accusations of coercion and manipulation.
>
> I don't see voting having a role in any of this, except as a crude
> opinion poll for the internal equivalent of Marketing. Voting doesn't
> work in the real world, and in an online world where you can't even
> make someone respond to your email, I see it being even less
> effective.
>
> How's this sound?
>
> Nat
Corporate and diplomatic, but worth a shot. If it even has a _chance_ at
keeping fair play in the community, I'll support it. It apparently does, though
I'm wondering how different this is from the current setup.
Points of clarification, however. QA team determines definite preparedness for
release? No two or more members of a single company on (QA Team|Any Team)? If
any team, for the purpose of development, it's not entirely logical/feasable,
is it? For the purpose of determining the quality of a potential release or
code fix, etc., it's one step in the right direction. Would this team be able
to return crippled features to developers for rethinking (extending,
embedding)?
Thanks again for your tolerance and even-handedness, Nat.
Group: I have now had seventeen requests to fork perl from people other than
"elitists" apparently joking (?) about it. The answer is ABSOLUTELY NO. Stop
asking. If _YOU_ fork it, don't consider yourself any advocate of Perl or this
community! The problems in this community are not solved by secession. Even if
it were technically feasable, it's absolutely disgusting to me, and I'll have
no part of it. I wish it were politically correct to curse!
