httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: xmodem vs. zmodem
Date Mon, 07 Jul 1997 21:10:15 GMT
>Then along came zmodem with sliding windows.  Send a bunch of packets,
>wait only if the window fills and you haven't received an ACK.  If the
>window is large enough to accomodate latency you can get almost the full
>bandwidth provided by the link. 

Nice analogy, but how do you control the window size when there are N
recipients, each of which is a human being with a possible 36 hour
delay between "seeing" packets?

I don't have a problem with occasional changes to the source that are
reviewed post-commit.  The problem occurs when many changes are committed,
often with poor documentation in the Log, and my personal "window size"
gets overloaded; I assume the same is true of others, since I note that
we all tend to miss the obvious when a large number of checkins go by.

What I would suggest is that we commit bug fixes and small changes
quickly and enforce a 48 hour window on large changes and new features.
I.e., if there are no negative comments within 48 hours, then go ahead
and commit, otherwise fix the thing according to the comments and then
commit (or don't commit at all).

As for progress on 1.2.x vs 1.3 vs 2.0, I think that will depend on
actively maintaining an Agenda for those versions, just as all of our
progress since I got back from Australia has been closely tied to how
the Agenda is driven.  We need multiple agendas (and multiple volunteers
to manage them) if we are to progress on multiple versions at once.
It might be a good idea to commit the Agenda to src on each branch
and just exclude it from the distribution tar.  That way, anyone with
cvs access can update the agenda.  Of course, we would still want to
post them to the list as well.

Actually, 2.0 will never get off the ground until a separate module is
created for 2.0 development, which requires fixing the ownership on CVSROOT,
which probably requires Marc or Brian fixing the clueless location
for the cvs passwd file problem first.

Unfortunately, these are just ideas -- I don't have the time right now
to put them into effect.


View raw message