httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r.pl...@t-online.de
Subject Re: Issues for 2.1.8
Date Tue, 20 Sep 2005 21:38:24 GMT


William A. Rowe, Jr. wrote:
> r.pluem@t-online.de wrote:
> 
>>

[..cut..]


> 
> I'd argue the opposite.  Do you notice how few people at any given time
> are following bugzilla?  Cleaning up and mopping up?  I've done my 400+
> hours of time on that side, and am likely to jump back in from time to
> time, but it's unfair to throw unstable code out into the general (read:

I know that this is a problem and for sure I have to admit that I should
do more on PR's. I think everybody appreciates your efforts
on the bugzilla frontier here. So some honest question (I really don't know the answer):
>From your experience in the past: Is the number of PR's for experimental
modules that have not been handled by the driver(s) of these modules remarkably
higher than for other parts of httpd?
If yes, then these module shouldn't be in the experimental section of a stable
branch.

> non-developer) community and have it all land on the backs of five folk
> who may or may not be interested in that specific flakey module.

I understand your concerns and I know that users are sometimes the way:
"Hey its in the stable release, so it should work and I want it to be fixed".
And as I mentioned special care must be taken to decide which modules can
remain in the experimental section of a stable branch and which not. Of course
the driver(s) of these modules should remain commited to handle the PR's
and patches coming in. Furthermore the module should have a minimum level
of quality. I know these are very "soft" definitions from my side and that is
a weak spot.


> 
> It got fixed not because there were more testers, but as often as not,
> because there were developers who -cared-.  So, if those same developers

Of course they got fixed because developers cared and did good work. But they
also got better because people used them, found bugs (some resulting in PR's,
some in patches), edge cases and proposed new features. So you need both sides

> who care want to see their module in GA, it better be something better
> than unstable before we inflict it on the entire user community.  So if
> there is a higher bar for GA, does that mean that
> 
> Of course, these are alphas/betas.  There is no reason not to keep these
> modules in every alpha release.  Drop them from the beta to avoid user's
> confusion when they see the GA.
> 
> The better answer; if they won't be release quality in 2.2.0, we should
> simply svn rm them from 2.2.x branch.  They live on, in trunk :)

Thats the problem I see. That means that they will only be used by few
and there is not that big feature or bug feedback from the community.

> 
> And best yet, the developers *should* encourage other devs and power
> users to try out snapshots until they are beta quality.  Drop them into

This is not possible for all that people, because of various reasons, e.g.

- Dependance on third party modules
- Dependance on support contracts
- Management decision

There may be thousands of reasons why these should not block power users from
using snapshots, but in most cases these reason does not matter to management
people.

> httpd.apache.org/dev/dist/ - that's where unstable/unproven code really
> belongs.  Once we hear back 'good things', then the entire project

As said before we should not have unproven code in the experimental section.

> should be willing to support these new modules.
> 
> Bill
> 
> 

Regards

RĂ¼diger

Mime
View raw message