Intel Port & Release Process

[Ben Hyde <bh...@pobox.com>]

There are only two issues here I care deeply about.

   1. The state of the Intel port.
   2. The release process.

On all those other issues I wish I could stay silent
so discussion focused just on these two.  Worse yet would
be if I introduced yet more issues, like say: the
shocking lack of a testing harness.

The Intel Port

I wrote a web server before Netscape existed, and I've
a lot of high volume sites using it.  When it became
clear that finally the market had stablized enough I
made the choice to replace it with Apache+module.

That choice was quite hard.  The lack of an NT solution
meant that two of my largest sites would be left in
the cold.  The lack of a VMS/Vax solution means one
of them is left in the cold.  This is almost impossible
to do to paying customers!

Meanwhile when we poll our customers I find frightening
trends toward NT (not to be confused with the New 
Testament).  ALL of our customers have corp.
policies to migrate ENTIRELY to the NT. 

It matters little that these policies in most
organizations were instituted to drive out the Mac
installed base with it's minority representation at
the IT table it has rapidly spreading to
the Unix machines as well.  NT backoffice market
penetration is one of Microsoft's top goals this
year.

So when I made the choice to move to a third party
web server, Apache, Netscape or MSoft were the ovious 
choices with each choice making some customers mad.
The NT port of Apache won the day.  I could say I
was choosing the market leader, and yes there was
an NT solution for them.

OK, so now I'm committed.  I'm very happy with the
choice.  Apache is a lovely peice of work.  The team
is a pleasure to work with.  I was amazed at the
sophistication, and on topic character of the list.
[I'm glad I didn't join up this week :-)].

That said the NT Port has real troubles.  I'll try
to enumerate a concise list in another posting, but
suffice it say if this was a comercial project
under my control I'd be transfering unwilling, but 
senior, labor it.

Release Process

I think the voting it's too severe as is.  I've seen
many projects that used CVS with a high degree of 
trust in the developers, and I don't see why it wouldn't
work well here.  It is approprate to have a little review
very close to the releases, and when updating the
"stable" release.

It's a no win choice what to do with 1.3 now.  The
unix stuff, sorely needs releasing.  The Win stuff
absolutely is not ready.  Spliting them would be
VERY bad for Apache's market share.  The immovable
needs of the unix installed base versus the irrisistable
force of the Window's mopping up in IT organizations;
it should make for interesting times.

Since my market is much more severely in the midst
of that mopping up, it's hard for me to get
enthusastic about splitting them up.

 - ben
---
"Crowds have always undergone the influence of
illusions.  Whoever can supply them with those
illusions is easily their master; whoever attempts
to destroy their illusion is always their victum."

Re: Intel Port & Release Process

[Brian Behlendorf <br...@organic.com>]

At 05:40 PM 1/9/98 +0000, Ben Laurie wrote:
>Marc Slemko wrote:
>> The problem is that much of the code here is more interrelated and needs
>> to be better on a per line basis because it simply isn't as big as some
>> projects.  Voting has raised a heck of a lot of objections to all sorts of
>> patches, mine included.  You can do this stuff after the fact, but the
>> problem is that if no one has time to pursue it, it just falls away.
>
>I'd say that the solution to this is to say that if anyone has a problem
>with a particular patch then it MUST be backed out and use the
>review-then-commit model.

I'd go for this too.  

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects				  brian@organic.com

Re: Intel Port & Release Process

[Ben Laurie <be...@algroup.co.uk>]

Marc Slemko wrote:
> The problem is that much of the code here is more interrelated and needs
> to be better on a per line basis because it simply isn't as big as some
> projects.  Voting has raised a heck of a lot of objections to all sorts of
> patches, mine included.  You can do this stuff after the fact, but the
> problem is that if no one has time to pursue it, it just falls away.

I'd say that the solution to this is to say that if anyone has a problem
with a particular patch then it MUST be backed out and use the
review-then-commit model.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Re: Intel Port & Release Process

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

On Fri, 9 Jan 1998, Ben Hyde wrote:

> 
> That said the NT Port has real troubles.  I'll try
> to enumerate a concise list in another posting, but
> suffice it say if this was a comercial project
> under my control I'd be transfering unwilling, but 
> senior, labor it.

The STATUS file should be changed to have a section just for NT problems,
and we should try to get all known problems in there, including features
that are really needed.

All lists of problems are always welcome.

> Release Process
> 
> I think the voting it's too severe as is.  I've seen
> many projects that used CVS with a high degree of 
> trust in the developers, and I don't see why it wouldn't
> work well here.  It is approprate to have a little review
> very close to the releases, and when updating the
> "stable" release.

The problem is that much of the code here is more interrelated and needs
to be better on a per line basis because it simply isn't as big as some
projects.  Voting has raised a heck of a lot of objections to all sorts of
patches, mine included.  You can do this stuff after the fact, but the
problem is that if no one has time to pursue it, it just falls away.

Some sort of "stuff" tracking system would be good, but not as heavy
weight as the bugdb.  It could include comments about things that could
use changing, even if they aren't bugs, ideas, suggestions for features,
etc.

Oh, I had a good laugh about the bug tracking system that ships with
visual studio.  It is the "anomaly tracking system".  Perhaps we need an
anomalydb instead?  <g>