minor features and changes

[Marc Slemko <ma...@znep.com>]

There are various little features and changes that have been backing up
for an awfully long time.  While we figure out a path for the major
changes that are going to be made in 1.3 and for 2.0, I don't see why
development shouldn't move ahead.

Any objections to me (and hopefully others...) starting to get moving
again on patches and changes that are relatively minor things compared to
the API and threads and abstraction related? 

Re: minor features and changes

[Chuck Murcko <ch...@topsail.org>]

Rob Hartill wrote:
> 
> On Sat, 7 Jun 1997, Marc Slemko wrote:
> 
> > There are various little features and changes that have been backing up
> > for an awfully long time.  While we figure out a path for the major
> > changes that are going to be made in 1.3 and for 2.0, I don't see why
> > development shouldn't move ahead.
> >
> > Any objections to me (and hopefully others...) starting to get moving
> > again on patches and changes that are relatively minor things compared to
> > the API and threads and abstraction related?
> 
> Have we decided on a path ?
> 
> it's all terribly confusing from the various threads going on.
> 
> My preference..
> 
> Develop 1.3 and 2.0 in parallel and be prepared for emergency 1.2.X's.
> 
> 2.0      major revamp
> 1.3      1.2 + features - to live as long as there's support for it.
> 1.2.x    important bugfixes only - no features.
> 
My take on the current trees - 1.2.X and the HEAD - is this, looking
from the standpoint of the proxy:

Big fixes (there are a number of these) fold into both trees.
Minor enhancements fold into both trees.
Major enhancements (HTTP 1.1 support, new caching strategy, real
multiple alarm handling, not just a hack) go into HEAD as a testbed for
later deployment into 2.0. They'll also release in whatever HEAD gets
called. If that's 1.3, fine. If that's 2.0, then I'd have to consider
folding them back into the earlier final 1.X tree too.

But for a couple of days, I'm working on other things. Like sleep. Then
I plan to get back to work on both long and short term stuff.

I used to think I could wrap up the proxy and move back into the core
development more, but the bloody proxy has taken on a life of its own.
-- 
chuck
Chuck Murcko
The Topsail Group, West Chester PA USA
chuck@topsail.org

Re: minor features and changes

[Marc Slemko <ma...@worldgate.com>]

On Sun, 8 Jun 1997, Rob Hartill wrote:

> On Sat, 7 Jun 1997, Marc Slemko wrote:
> 
> > There are various little features and changes that have been backing up
> > for an awfully long time.  While we figure out a path for the major
> > changes that are going to be made in 1.3 and for 2.0, I don't see why
> > development shouldn't move ahead.
> > 
> > Any objections to me (and hopefully others...) starting to get moving
> > again on patches and changes that are relatively minor things compared to
> > the API and threads and abstraction related? 
>  
> Have we decided on a path ?
> 
> it's all terribly confusing from the various threads going on.
> 
> My preference..
> 
> Develop 1.3 and 2.0 in parallel and be prepared for emergency 1.2.X's.
> 
> 2.0      major revamp
> 1.3      1.2 + features - to live as long as there's support for it.
> 1.2.x    important bugfixes only - no features.

My problem is that this makes it even harder for 2.0 to ever happen.  For
the longest time, the plan for 2.0 has included multithreading, NT, and an
improved API.  Now much or most of that is perhaps going into 1.3.  I have
not followed the NT discussions, but I am wondering if 1.3 should be
either a make-do NT port (ie. minimal changes to have a reasonably
functional server on NT without rewriting more code than necessary) or 1.3
should be skipped and just push for 2.0. 

I am concerned that an attempt at a "quick" 1.3 release for NT will end up
taking just as long as going for 2.0 would and still leave things somewhat
fragmented. 

What about a 1.2-NT release?  How much of the current development group is
interested in NT work?  Do most people belong to one group or the other?
Would it be better for those who want a NT release soon to do it in a
seperate, not-for-unix tree as opposed to an integrated 1.3?

I do not object to work going on in the pre-2.0 area while 2.0 is begin
developed; in fact I support that and think the extra effort of
integrating changes not related to the API or threading, etc. is easily
managed.

Re: minor features and changes

[Rob Hartill <ro...@imdb.com>]

On Sat, 7 Jun 1997, Marc Slemko wrote:

> There are various little features and changes that have been backing up
> for an awfully long time.  While we figure out a path for the major
> changes that are going to be made in 1.3 and for 2.0, I don't see why
> development shouldn't move ahead.
> 
> Any objections to me (and hopefully others...) starting to get moving
> again on patches and changes that are relatively minor things compared to
> the API and threads and abstraction related? 
 
Have we decided on a path ?

it's all terribly confusing from the various threads going on.

My preference..

Develop 1.3 and 2.0 in parallel and be prepared for emergency 1.2.X's.

2.0      major revamp
1.3      1.2 + features - to live as long as there's support for it.
1.2.x    important bugfixes only - no features.

--
Rob Hartill                              Internet Movie Database (Ltd)
http://www.moviedatabase.com/   .. a site for sore eyes.