Re: Interesting Apache 2.0 project...

2002-02-13 Thread Jeff Trawick

"Padwa, Daniel" <[EMAIL PROTECTED]> writes:

> Justin's work on coordinating the .32 release has been extremely positive in
> this regard (way to go Justin!).   

+1!

>  A few more releases like this can
> probably get 2.0-gold out the door.  Without that kind of focus on and
> ownership of releases, it's going to be really hard to ship this thing.

^H^H^H^H^H^H^H^H^H^Hyou bet
-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...



Release procedures was Re: Interesting Apache 2.0 project...

2002-02-13 Thread Justin Erenkrantz

On Wed, Feb 13, 2002 at 11:32:46AM -0500, Padwa, Daniel wrote:
> > It could be a chicken-and-egg problem.  If the developers of those tools
> don't have a
> > lot of users asking for Apache 2.0 support, what is their motivation for
> providing it?  > They are probably like us, with lots of other things on
> their to-do lists.  If we had a > golden release, perhaps that would help
> change the situation.
> 
> Really not trying to throw out flamebait, but...
> 
> I think Greg hit the nail on the head here.There hasn't been much
> visibility to anyone not following this list (or even to many following it)
> of a timeline or roadmap to gold on 2.0.   Do people know that all the major
> interfaces are stable?Are they?

Nope.  We can only know that the major interfaces are stable by
receiving feedback.  Seeing how the input filters worked dictated
(in my mind) that we needed to change that interface.  However, I'm
hopeful that we won't encounter anything in the future.  As we get
more developer feedback, we can tweak the APIs.  However, once
we've decided on a GA release, our APIs should be fairly consistent.

> Is there yet a consensus on a timetable for getting this to gold, or is it
> still a "when it is ready" approach?   If the latter, it's going to be hard
> to get people very excited about even kicking the tires on the betas.

Well, true.  My emphasis is switching from development to getting
this to GA quality.  I'm probably not going to be adding new features
at this point.  Each developer will have to make that call on their
own.  My goal is now to see a stable GA-quality release hit rather
soon.  Personally, I've been using Apache 2.0 for my own websites
for a few months and haven't encountered any major issues.

> It's going to be really hard to build momentum towards a release without a
> release target and active release management.  According to the latest
> STATUS, we've had only one tag/roll event (2.0.31) in the last three months.

I believe .30 would have gone beta except for the fact that we
ran into a problem running it on daedalus.  .31 got hit by some
input filtering problems and Win32's brokenness.  And, .32 is far
better than .28 is.

> It's also confusing to customers when at least two vendors are distributing
> Web servers that are "based on 2.0" when 2.0 is still not fully baked.

Heh.  You're not the only one who finds it amusing that commercial
companies are distributing products based on something that we often
have trouble calling beta.  I blame it on the fact that we have
higher standards when there is no money to make off of it.  =)

> Justin's work on coordinating the .32 release has been extremely positive in
> this regard (way to go Justin!).   A few more releases like this can
> probably get 2.0-gold out the door.  Without that kind of focus on and
> ownership of releases, it's going to be really hard to ship this thing.

Hopefully, .32 will go out.  We can then get constructive feedback on
what's wrong and then move forward.  .32 would have been out sooner if
Win32 wasn't borked.  I felt that it was definitely worth the wait for
a beta to have functional Win32 support.  That was my call - I know
that some people would have made a different call.  So, it goes.

> PS> A simple roadmap and timeline, like the one that Subversion has at
> http://subversion.tigris.org/project_status.html, would go a very long way
> towards addressing these issues.

I suggested this a long time ago and got beaten down for it (I think
I referred to how Tomcat does it).  The majority of our developers
don't like the idea of enforcing timelines on a true group of
volunteers (those people who get paid are balanced out by the
different companies they work for).  SVN is a bit different because
the core contributors all work for the same company.  They have a
mandate from above to complete the task.  Over here, we're not that
structured where any one person has unquestioned pull over the group.

Our release procedures are like stabbing in the dark, but I can't
seriously come up with an alternative that works for our situtation.
The only thing I can do is take the RM responsibility and try to
shepherd a release out.  Hopefully, the rest of the group can keep
focused enough not to curtail my efforts.  -- justin




RE: Interesting Apache 2.0 project...

2002-02-13 Thread Padwa, Daniel

> It could be a chicken-and-egg problem.  If the developers of those tools
don't have a
> lot of users asking for Apache 2.0 support, what is their motivation for
providing it?  > They are probably like us, with lots of other things on
their to-do lists.  If we had a > golden release, perhaps that would help
change the situation.

Really not trying to throw out flamebait, but...

I think Greg hit the nail on the head here.There hasn't been much
visibility to anyone not following this list (or even to many following it)
of a timeline or roadmap to gold on 2.0.   Do people know that all the major
interfaces are stable?Are they?

Not faulting anyone here, just pointing out that in the eyes of people not
day-to-day involved, Apache 2 feels like it has been "almost ready" for a
very, very, very long time.Did the additional development time yield a
better product?   Absolutely.  But it did have a cost, at least in terms of
public perception and excitement.

Is there yet a consensus on a timetable for getting this to gold, or is it
still a "when it is ready" approach?   If the latter, it's going to be hard
to get people very excited about even kicking the tires on the betas.

It's going to be really hard to build momentum towards a release without a
release target and active release management.  According to the latest
STATUS, we've had only one tag/roll event (2.0.31) in the last three months.

It's also confusing to customers when at least two vendors are distributing
Web servers that are "based on 2.0" when 2.0 is still not fully baked.

Justin's work on coordinating the .32 release has been extremely positive in
this regard (way to go Justin!).   A few more releases like this can
probably get 2.0-gold out the door.  Without that kind of focus on and
ownership of releases, it's going to be really hard to ship this thing.

- Danny

PS> A simple roadmap and timeline, like the one that Subversion has at
http://subversion.tigris.org/project_status.html, would go a very long way
towards addressing these issues.



Re: Interesting Apache 2.0 project...

2002-02-13 Thread Greg Ames

Eli Marmor wrote:

> By the way: The main problem of Apache 2.0 (IMHO) is not stability
> (which is already higher than competing products), 

:) :) :)

btw, in less than an hour daedalus will have been running JRE_1 for 3 days.  The
only hiccup I'm aware of was the surprising behavior when ForceLanguagePriority
isn't coded.  wrowe has committed something to address that, which I will test
shortly.

> or performance (although it still keeps improving), or portability (which is
> excellent), or security (well, comparing to IIS...);
> 
> The main problem is that most of the complementing tools, such as the
> fcgi you mentioned (FastCGI), or the Apache's WBM of Webmin, or the
> various building/packaging tools (e.g. Apacompile), etc., are not yet
> working with Apache 2.0, but only with 1.3.*.
> 
> This is, from my impression, the main reason that stops people to
> move to Apache 2.0.

It could be a chicken-and-egg problem.  If the developers of those tools don't
have a lot of users asking for Apache 2.0 support, what is their motivation for
providing it?  They are probably like us, with lots of other things on their
to-do lists.  If we had a golden release, perhaps that would help change the
situation.

Greg



Re: Interesting Apache 2.0 project...

2002-02-13 Thread Eli Marmor

Martin Kraemer wrote:
> 
> On Tue, Feb 12, 2002 at 02:25:40PM -0500, Bill Stoddard wrote:
> > ...
> Indeed -- but then it's no longer CGI (different interface), so you
> lose all the CGI applications. There has already been fcgi (in an attempt
> at providing "almost" source level compatibility, and winning speed by
> recycling processes instead of forking all the while).

By the way: The main problem of Apache 2.0 (IMHO) is not stability
(which is already higher than competing products), or performance
(although it still keeps improving), or portability (which is
excellent), or security (well, comparing to IIS...);

The main problem is that most of the complementing tools, such as the
fcgi you mentioned (FastCGI), or the Apache's WBM of Webmin, or the
various building/packaging tools (e.g. Apacompile), etc., are not yet
working with Apache 2.0, but only with 1.3.*.

This is, from my impression, the main reason that stops people to
move to Apache 2.0.
-- 
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.:   +972-9-766-1020  8 Yad-Harutzim St.
Fax.:   +972-9-766-1314  P.O.B. 7004
Mobile: +972-50-23-7338  Kfar-Saba 44641, Israel



Re: Interesting Apache 2.0 project...

2002-02-12 Thread Martin Kraemer

On Tue, Feb 12, 2002 at 02:25:40PM -0500, Bill Stoddard wrote:
> 
> This is an interesting exercise in that we will need manipulate the blocking 
>behaviour of
> the network layer from the top of the filter stack.

Indeed -- but then it's no longer CGI (different interface), so you
lose all the CGI applications. There has already been fcgi (in an attempt
at providing "almost" source level compatibility, and winning speed by
recycling processes instead of forking all the while).

Also, RFC2388 might be interesting to implement some day...

   Martin
-- 
<[EMAIL PROTECTED]> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730  Munich,  Germany