Re: Re: about your concept

On Thu, Jul 22, 2004 at 08:50:02PM -0500, Thomas wrote:
> On Thursday 22 July 2004 02:53, Andrew Suffield wrote:
> > > And then *you* used the fact that you knew the head developer to merge in
> > > a complete reworking of the network protocol without a sentence of
> > > discussion on the mailing list until *after* you had merged the code in.
> >
> > I very much doubt that it was significantly affected by the fact that
> > I've known Mark for a while, and rather more by the fact that I
> > provided an arch archive and something Mark was interested in.

> With absolutely no review outside of the two of you.

And absolutely no reason why there should be.

> At the very least, it is nice 
> to announce that you are making those changes to the developer mailing list, 
> so that other developers won't spend time doing what you are doing, or 
> writing code that would be affected by your changes.  I would also like to 
> note that this isn't just some rule I made up, but seems to be a common 
> suggestion/guideline/rule for most open source projects that have or are 
> looking to attract developers outside the core developer base.

I've never seen a serious project that did that. You're
misunderstanding how they operate. But that's beside the point anyway.

There aren't any serious developers other than me and Mark (and
possibly Phil in the near future). Deal with it. Our primary focus has
been on cleaning up the mess and getting the tree into a fit shape for
real development. There won't be many serious developers until this is
complete, and probably not afterwards either.

> > I don't see why you think the mailing list had anything to do with
> > it. It is a discussion forum, nothing more. I can talk to people
> > without using it quite easily. Not that there was much to discuss; we
> > both knew more or less what needed to be done.

> The mailing list has everything to do with it exactly because it is a place 
> for discussion.  The problem is you are assuming that what you and Mark both 
> "knew more or less" was correct.

Because we know what we're doing and most if not all of the people on
the list do not.

> > > At which point
> > > you called anybody who thought there was a better or different way
> > > "stupid" and "insane" and refused to listen to anybody else's opinion.
> >
> > Fiction.

> Not true at all, here are some choice quotes.  I have taken them from a thread 
> titled "Proposal for a minor change in the Y-protocol", specifically 
> discussing whether commands between the client and server should be passed as 
> strings or as integers,

No, that is not what it was discussing.

> one of the major changes you made to the code without 
> any formal announcement or design discussion on the list.

And a very good example of why discussing it on the list would have
been a waste of time.

> "And this is insane. The protocol would change depending on hardware 
> architecture", "What are you smoking? Alignment is as hardware-dependent as 
> endianness.", " You have to be really stupid to write socket code with 
> alignment issues."

Yet strangely you can't see how this is not what you said above
(especially with the context deleted). That says it all really.

> You might have had some good points, but the fact is, you were rude and 
> responded to criticism in a way that stifled discussion and discouraged 
> people from participating.

Good, that person was supposed to be discouraged from
participating. Their participation was not useful or welcome; they
demonstrated a complete and profound lack of understanding of the
subject.

> After all, who would want to point out a flaw in 
> your argument when they know they are going to be called "stupid" and 
> "insane."

When the "flaw" they were pointing out took roughly the form of "This
is wrong because the moon is made from green cheese", then that would
seem appropriate to me. It *was* both stupid and insane.

> This does not just affect the people you are replying to directly, 
> but anybody who is reading the discussion and considering contributing.

No, that's quite wrong.

> First, it is not up to you to decide who is too stupid to contribute code, 
> especially when you have not seen their code.

Don't be silly. It is always up to me to determine my actions. Appeals
to authority are fallacious.

> In the above case, the suggestion which you claimed would flat out not work 
> clearly would work, as it has worked in X for around 20 years or so, even 
> between hosts of different endianness.

And that's the sort of total reality disconnect they demonstrated
too. This simply isn't true. It's vaguely the same sort of colour as
something that is true, but that doesn't buy you anything. The
proposal was to align all integers on 4-byte boundaries, presumably
from the start of the stream (which makes no sense in a stream
protocol). It's an insane proposal. X11 most assuredly does not do
this.

> > The review process is Mark
> > (and occasionally me) looking at the code, and not every discussion
> > about the project happens on this list. Not least because of all the
> > people who chime in with ill-educated opinions.

> What I meant by "some sort of review process" was 
> actually: "some sort of open review process".  In my opinion, it is 
> necessary, especially for a new project still trying to attract developers, 
> that they make their goals and guidelines clear and open, and not rely on a 
> single developer to review and comment on all code submitted, plus one person 
> who "occasionally" reviews code, and who's influence over the acceptance 
> process is completely unknown.

Your opinion is wrong. Reality belies it. Pretty much no serious
projects do this.

> > > You have probably lost many smart and talented contributers to
> > > the project because you a) ignored them completely, or b) called them
> > > idiots as soon as you see what *might* be a better way to do something,
> > > or just didnt feel like looking at their code.
> >
> > I rather doubt that. We've lost a fair amount of dead weight though.

> Certainly we have lost a lot of dead weight, that much is obvious from the 
> lack of "Y crashes on startup" and "Y wont compile" posts.  However, there 
> were also a lot of people discussing and doing development who seem to have 
> dissapeared from the discussion and development.

No, nothing that reasonably qualifies as "development" has disappeared.

> > > In order for such a large project to succeed, there needs to be a large
> > > and receptive group of core developers who can lead intelligent
> > > discussions and make fair decisions about what to put into the code, or
> > > provide good explanations as to why something *doesnt* end up in.
> >
> > No. I don't know where you got that idea. Quite the opposite really -
> > for a large project to succeed, you need a (small) group of
> > gatekeepers whose primary task is to say "no". That's the hallmark of
> > every successful large free software project (Larry Wall gives a
> > rather good talk on the subject).

> Perhaps saying that there needs to be a "large" group was an overstatement.  
> Certainly there needs to be more than one or two people controlling access to 
> the repository.  In another thread where somebody wondered how Linus managed 
> the Linux kernel development, you said "they use bitkeeper, we use arch".  
> That only matters if more than one person has write access to the repository.  
> If only one person can write to it, it doesn't matter that it exists, as far 
> as code submission goes, because there is still only one person who can use 
> it.

You have stunningly failed to understand bitkeeper, arch, and the
development model used by Linux. We're doing it the right way, and
we're also coincidentally fairly close to how Linux does it (and there
is precisely one person controlling access to each significant branch
for Linux). It is possible to scale up to more than one or two people
(this is in the process of being built for arch, for the development
of tla itself), but it is certainly not necessary.

> Generally, when a large project (see below) succeeds with only one or two core 
> developers, as Linux did for so long, it is because that core was able to 
> commit a lot of time to the project, was receptive to suggestions about where 
> the project should go, design, etc, and was willing to promote discussion and 
> admit they were wrong.

That's quite entertaining, given how several of us here recall the old
debate over microkernels. Linux is where it is today precisely because
Linus is not "receptive to suggestions", and has a firm idea of where
the project should go and won't let people distract from that.

> This is not to say that the size of the core development team is the only 
> problem here.  The openness (or lack thereof) is another issue I believe 
> needs to be addressed.  As we saw with the XFree86 project, even though there 
> was a reasonably sized (in my opinion) core group of developers, the fact 
> that they were unwilling to listen to outside opinions or participate in 
> discussions led to the forking of the project.

That's an impressive misunderstanding of what happened to xfree86. It's wrong.

> > This isn't a large project anyway.

> Perhaps at this moment there are not many developers and there is a small code 
> base, but this is an incredibly ambitious project, and at some point, if the 
> project is to succeed and be developed at a reasonable pace, it will have a 
> large number of developers and a large codebase.

No.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBARS3lpK98RSteX8RAsAnAJ0WeMXvqxfReQw9D7cDPITXfcAu7ACcCyTK
BOI+1xBUymqX5GF+u/Odu78=
=7SXL
-----END PGP SIGNATURE-----