Mail problems? [simon@cozens.net: Re: Now, to try again...]
This is the fourth time I've sent this mail to perl6-internals-api-parser, but it doesn't seem to be arriving. None of my other mail is affected, and perl5-porters is, for once, behaving itself; why this list in particular? - Forwarded message from Simon Cozens [EMAIL PROTECTED] - Damn this is annoying. Is it perl.org that's dropping mail or me? - Forwarded message from Simon Cozens [EMAIL PROTECTED] - On Sat, Dec 16, 2000 at 08:09:23PM +, David Grove wrote: Thinking of just the parser as a single entity seems to me to be headed into trouble unless we can define in advance what type of role these dialects will play in the language, and at what point they merge into a single entity and how. I can understand each word in this sentence, but put together they don't appear to make much sense. I think you're getting needlessly hung up on this idea of "dialects", whatever you seem to believe they are. We're not parsing dialects, we're parsing *COMPLETELY DIFFERENT THINGS*. Python is not a dialect of Perl. There are a number of ways we could do this. We could allow the user to use source filters to turn Python into Perl, which is what happens currently, with some success. We could allow the user to write their own parser and turn Python into an op tree, which allows much greater flexibility. Or, we could allow the user to override parts of the parser's operation, allowing for ease of modification. Or all three. (or worse, multiple "parser/lexer/tokenizer single-entity parts"... meaning redundant duplication of extra effort over and over again repeatedly). Huh? I'm just thinking of a system of callbacks. You can overload operators in Perl, and while this is slightly confusing, it isn't earth-shattering. Now, I'm hoping that you'll be able to overload parser operations in Perl 6. - End forwarded message - -- Almost any animal is capable learning a stimulus/response association, given enough repetition. Experimental observation suggests that this isn't true if double-clicking is involved. - Lionel, Malcolm Ray, asr. - End forwarded message - -- Sigh. I like to think it's just the Linux people who want to be on the "leading edge" so bad they walk right off the precipice. (Craig E. Groeschel)
Re: Now and then
David Grove wrote: 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? I think it's not feasible generally. Maybe if you tighten up your definition of "single company". For example, I work for a company with over 35000 employees all over the country. Who knows how many of them would want to participate in p6 development? It shouldn't matter, because my company has no interest in the direction p6 takes, and would never, ever meddle in the way you fear. Also, your limit of 2 per committee doesn't make much sense, since a committee might only have 3 members, in which case 2 is a majority. Make strict minority is a better spec. -- John Porter
Re: Now and then
Uri Guttman writes: that resonates with MMM totally. look at the surgical team approach as well but updated. each group has a lead and a 2nd (and possibly 3rd) in charge. others in the group do work on various parts under control of the group leaders. support types like QA, version control, docs management, can be shared among groups. I'm not sure I like the idea of a lead. I think all three (QA, source, user liaison) should be equal partners. I think each group's list should be open to public contributions. The point is to encourage public participation in the ongoing maintenance. Then again, remember the hassles we had with the perl6-* lists? Nobody knew how to deal with topics that overlapped lists. You had to know all the groups to decide which it was appropriate for. Are these big enough hassles to suggest that perhaps the perl5-porters All In One list wasn't such a bad idea after all? Nat
Re: Now and then
On Wed, Oct 11, 2000 at 09:41:30AM -0600, Nathan Torkington wrote: Then again, remember the hassles we had with the perl6-* lists? Nobody knew how to deal with topics that overlapped lists. You had to know all the groups to decide which it was appropriate for. Are these big enough hassles to suggest that perhaps the perl5-porters All In One list wasn't such a bad idea after all? Perhaps. Even though there was a lot of traffic, much of it was easy to follow because a significant proportion of it was consistently titled - RFC ## (v#): Add XYZ into Perl. That traffic is also easy to find in the archives. That will probably be less of an issue with a strong lack of RFC activity during the implementation phase. It very well could be that anyone doing serious work is going to subscribe to perl6-all, and the perl6-* lists exist for those who just want to listen. Z.
RE: Now and then
David Grove writes: I'm wondering how different this is from the current setup. Currently there's the pumpking and the pumpking decides when to release a new version of Perl. This exposes the pumpking to all sorts of allegations, and potentially exposes Perl to being bought out. When no single person can force a release through, both problems go away. It's distributing the current pumpking's responsibility (integrating patches, quality control, communication and deadlines) to more people. This has the added benefit of hopefully avoiding pumpking burnout. Points of clarification, however. QA team determines definite preparedness for release? It's a joint decision. If QA likes it, but the code person doesn't, they have to sort that out between themselves before the release can happen. If the user liaison says "we've been promising this for the last three releases, we can't make another release without it" then the others have to listen. But nothing can be released without QA's approval. Nat
RE: Now and then
On Wednesday, October 11, 2000 11:02 AM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] wrote: David Grove writes: I'm wondering how different this is from the current setup. Currently there's the pumpking and the pumpking decides when to release a new version of Perl. This exposes the pumpking to all sorts of allegations, and potentially exposes Perl to being bought out. When no single person can force a release through, both problems go away. It's distributing the current pumpking's responsibility (integrating patches, quality control, communication and deadlines) to more people. This has the added benefit of hopefully avoiding pumpking burnout. Points of clarification, however. QA team determines definite preparedness for release? It's a joint decision. If QA likes it, but the code person doesn't, they have to sort that out between themselves before the release can happen. If the user liaison says "we've been promising this for the last three releases, we can't make another release without it" then the others have to listen. But nothing can be released without QA's approval. Nat Yes, that satisfies my concerns by providing "checks and balances" to the system. Bjarne Stroustroup in "The Design and Implementation of C++" talks about ANSI and the C++ committees, and how he's always tried to get real strings into the language as a basic data type, but every time he brings up the subject either Dennis Ritchie or a chinese lady whose name escapes me raises her hand and with that it's all over. The setup there is that it has to be unanymous. The need for unanymity slows down the process, but provides for a completely stable C++ implementation. I'm not sure that unanymity wouldn't be going overboard for Perl, but that would be a decision internal to the QA group, correct? Or something determined by Larry? There's definite pros and cons each way. Basically, the cons are that some things would never end up in the perl core, and the pros are that certain things would never end up in the perl core, like temporary and experimental "fixes" that don't work implemented mainly for a marketing stunt and that have the byproduct of disabling major features of the language... Have I tangented with this, or are we still making sense to each other?
RE: Now and then
David Grove writes: I'm not sure that unanymity wouldn't be going overboard for Perl, Except that it's not unanimity of individuals, who are cantankerous and troublesome, but unanimity of teams. Each team has the moderating influences of three people to try to reach consensus. The release manager might work with a team that can't agree to help them reach a decision, but nobody would be imposing will from above. but that would be a decision internal to the QA group, correct? The QA group ain't special. It has a role to play, but so do the code maintainers and the user liaison folks. Have I tangented with this, or are we still making sense to each other? You seem still to be making sense. Are we agreed that we have a good ongoing model to try when we get to that stage? Nat
RE: Now and then
On Wednesday, October 11, 2000 2:34 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] wrote: David Grove writes: I'm not sure that unanymity wouldn't be going overboard for Perl, Except that it's not unanimity of individuals, who are cantankerous and troublesome, but unanimity of teams. Each team has the moderating influences of three people to try to reach consensus. The release manager might work with a team that can't agree to help them reach a decision, but nobody would be imposing will from above. but that would be a decision internal to the QA group, correct? The QA group ain't special. It has a role to play, but so do the code maintainers and the user liaison folks. Have I tangented with this, or are we still making sense to each other? You seem still to be making sense. Are we agreed that we have a good ongoing model to try when we get to that stage? Nat I agree that it's moving it a positive direction, yes. Especially when no two or more members from a given - company is not a right word here, Nat... - "point of view" (ActiveState, Solaris, Digital Unix - no, er, "qlique"(?)) would be on a team. How to define that would be difficult, but the effect would have to be better than before. That would almost have to be a judgement call by the team manager. If I understand correctly, large teams would have a small team of "control" (bad word, but I don't know how else to put it) with a team manager for that team, and small teams (like the ones with two or three members, that have been pointed out) would be their own "control" team, and unanymity of teams would be required for release, is that a good summation? Anyway, it's definitely moving in a good direction, and shows potential to solve a majority of problems. Yes, this is a good direction.
RE: Now and then
David Grove writes: If I understand correctly, large teams would have a small team of "control" (bad word, but I don't know how else to put it) with a team manager for that team, and small teams (like the ones with two or three members, that have been pointed out) would be their own "control" team, and unanymity of teams would be required for release, is that a good summation? I think so, although I'd have written it better. The ongoing maintenance of Perl will involve work done by teams of people. Each team focusses on an area: compiler, regex, documentation, etc. The teams will obviously work together at time. Each team has three roles identified: the person who checks in patches, the person who represents user interest in that area, and the person who QAs that area. There may be others, members of the public, but these three are the ones who must be satisfied with a release before it can go out. There is no team leader, merely the union of those three people. The release manager is there to help each team work with its team members, and to help teams work together. The system is self-balancing. The release manager cannot override a team that will not approve a release. If teams want to kick out the release manager, they can get together and do so. The release manager should be involved in intra-team disputes to ensure that booting a team member out is an action of last resort and not merely a way to force a release through over valid objections. Anyway, it's definitely moving in a good direction, and shows potential to solve a majority of problems. Yes, this is a good direction. What else is there to say? I want to get this topic dealt with so we can return to the more pressing tasks: - how will we evolve and record design decisions (the RFC or RFC-replacement) - by which people and in what groups will design take place? I tend to lose patience with any thread that goes on for longer than three days, so we're reaching the end of my ability to focus here :-) Nat
RE: Now and then
On Wednesday, October 11, 2000 3:45 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] wrote: [snip[ documentation, etc. The teams will obviously work together at time. Each team has three roles identified: the person who checks in patches, the person who represents user interest in that area, and the person who QAs that area. There may be others, members of the public, but these three are the ones who must be satisfied with a release before it can go out. There is no team leader, merely the union of those three people. The release manager is there to help each team work with its team members, and to help teams work together. The system is self-balancing. The release manager cannot override a team that will not approve a release. If teams want to kick out the release manager, they can get together and do so. The release manager should be involved in intra-team disputes to ensure that booting a team member out is an action of last resort and not merely a way to force a release through over valid objections. [snip] Everything 100% A-OK, clear, agreed, and sounds wunnerful. Anyway, it's definitely moving in a good direction, and shows potential to solve a majority of problems. Yes, this is a good direction. What else is there to say? I want to get this topic dealt with so Naw, I just meant that it sounds good in theory. As you've pointed out, it just needs to be seen in actual practice. Also, IIRC, it has to be "approved". I tend to lose patience with any thread that goes on for longer than three days, so we're reaching the end of my ability to focus here :-) That's fine, you've been patient, considerate, understanding, and extremely helpful. You deserve a nap... or a beer, your choice.
RE: Now and then
David Grove writes: That's fine, you've been patient, considerate, understanding, and extremely helpful. You deserve a nap... or a beer, your choice. Having done what they said couldn't be done (making David Grove happy with Perl) I'm off for a Guinness! Nat (and then a nap :-)
