Re: Add 2.2.4 to bugzilla

[Sander Temme]

On Jan 11, 2007, at 1:40 PM, Ruediger Pluem wrote:

A week sounds good to me. I guess some of them are my fault as I  
only set
them to resolved fixed and never visited them again as I thought  
that they reached
their final state. Now I found out that you only have the option to  
close it once
it has moved to a 'resolved' state and 'closed' should be the final  
state.

I will take better care of this in the future.

Is there any chance to close all the ones in resolved state that  
have not been

touched for a week in one blow?


Absolutely. You can operate on the entire contents of a query  
result... which gets the job done and will send lots of e-mail.


Yes, Closed should be the final resting place for bug reports, for  
good or for bad.


Any interest in trying to codify the life cycle of PRs in Bugzilla  
and their dance around releases?  I can see if I have time to throw  
something in svn but then I'd want to hear from the folks who  
actually spend a lot of time in the system.


S.

--
[EMAIL PROTECTED]http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF




smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: r495422 - in /httpd/site/trunk: docs/dev/release.html xdocs/dev/release.xml

[William A. Rowe, Jr.]

[EMAIL PROTECTED] wrote:
> Author: rpluem
> Date: Thu Jan 11 14:48:47 2007
> New Revision: 495422
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=495422
> Log:
> * - Clarified location of release.sh script
>   - minotaur is an internal server name. Replaced it with people.apache.org
>   - Added a reminder to add the new release to Bugzilla

Looks great, thanks!

Re: Add 2.2.4 to bugzilla

[Ruediger Pluem]

On 01/11/2007 10:22 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
> 
>>Hi,
>>
>>could someone please add version 2.2.4 to the product Apache httpd-2 in 
>>bugzilla?
>>Are there any ideas how we can document / automate this as part of the 
>>release process?
>>This issue pops up regulary after each release.
> 
> 
> My bad, sorry, it's already been done.
> 
> http://httpd.apache.org/dev/release.html from
> http://svn.apache.org/repos/asf/httpd/site/trunk/xdocs/dev/

Thanks for the pointers. I tweaked release.xml a little bit.
If there are no objections I will update the site in 24 hours.

Regards

Rüdiger

Re: Add 2.2.4 to bugzilla

[Ruediger Pluem]

On 01/11/2007 10:12 PM, Sander Temme wrote:
> 
> On Jan 11, 2007, at 12:42 PM, Ruediger Pluem wrote:
> 
>> could someone please add version 2.2.4 to the product Apache  httpd-2
>> in bugzilla?
> 
> 
> Done.

Thanks.

> 
>> Are there any ideas how we can document / automate this as part of 
>> the release process?
>> This issue pops up regulary after each release.
> 
> 
> Hard to automate... but we could include it in the release checklist: 
> Ask Bugzilla admin to add new version. I am one, and will be happy to 

I am happy to add it to this list once somebody gives me a pointer where to
find it. I only found the shell scripts for creating the tar balls.


> ...and 183 in Resolved or Verified:
> 
> http://issues.apache.org/bugzilla/buglist.cgi?product=Apache%
> 20httpd-2&version=2.2-
> HEAD&version=2.2.0&version=2.2.2&version=2.2.3&version=2.2.4&bug_status=
> RESOLVED&bug_status=VERIFIED
> 
> Of the latter:
> 
> 60 are Resolved, Invalid
>  7 are Resolved, Wontfix
>  1 is  Resolved, Later
> 37 are Resolved, Duplicate
> 70 are Resolved, Fixed
>  8 are Resolved, Worksforme
>  0 are Verified
> 
> These can probably be closed in some way, shape or form.  What do you 
> think is sufficient inactivity to amount to lazy verification of a 
> Resolution transition?  A week?  Can I get a hum on that?

A week sounds good to me. I guess some of them are my fault as I only set
them to resolved fixed and never visited them again as I thought that they 
reached
their final state. Now I found out that you only have the option to close it 
once
it has moved to a 'resolved' state and 'closed' should be the final state.
I will take better care of this in the future.

Is there any chance to close all the ones in resolved state that have not been
touched for a week in one blow?


Regards

Rüdiger

Re: Add 2.2.4 to bugzilla

[William A. Rowe, Jr.]

Ruediger Pluem wrote:
> Hi,
> 
> could someone please add version 2.2.4 to the product Apache httpd-2 in 
> bugzilla?
> Are there any ideas how we can document / automate this as part of the 
> release process?
> This issue pops up regulary after each release.

My bad, sorry, it's already been done.

http://httpd.apache.org/dev/release.html from
http://svn.apache.org/repos/asf/httpd/site/trunk/xdocs/dev/

knock yourself out :)

Re: 2.2.4 windows binary w/ssl?

[William A. Rowe, Jr.]

Issac Goldstand wrote:
> 
> I'd agree if mod_ssl is disabled by default, but if it is, why are they
> downloading the mod_ssl-enabled installer?

You miss the point, it's illegal in some jurisdictions to possess/use
such cryptography.  That installer will remain as a service to those
communities, nothing more.

Re: Add 2.2.4 to bugzilla

[Sander Temme]

On Jan 11, 2007, at 12:42 PM, Ruediger Pluem wrote:

could someone please add version 2.2.4 to the product Apache  
httpd-2 in bugzilla?


Done.

Are there any ideas how we can document / automate this as part of  
the release process?

This issue pops up regulary after each release.


Hard to automate... but we could include it in the release checklist:  
Ask Bugzilla admin to add new version. I am one, and will be happy to  
do this ahead of the release. However, I usually space on it.


The combined 2.2.x versions have 198 bugs in (New, Assigned,  
Reopened, NeedInfo):


http://issues.apache.org/bugzilla/buglist.cgi?product=Apache 
+httpd-2&version=2.2- 
HEAD&version=2.2.0&version=2.2.2&version=2.2.3&version=2.2.4&bug_status= 
NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO


...and 183 in Resolved or Verified:

http://issues.apache.org/bugzilla/buglist.cgi?product=Apache% 
20httpd-2&version=2.2- 
HEAD&version=2.2.0&version=2.2.2&version=2.2.3&version=2.2.4&bug_status= 
RESOLVED&bug_status=VERIFIED


Of the latter:

60 are Resolved, Invalid
 7 are Resolved, Wontfix
 1 is  Resolved, Later
37 are Resolved, Duplicate
70 are Resolved, Fixed
 8 are Resolved, Worksforme
 0 are Verified

These can probably be closed in some way, shape or form.  What do you  
think is sufficient inactivity to amount to lazy verification of a  
Resolution transition?  A week?  Can I get a hum on that?


If any of the former still exist in 2.2.4, they should be moved to  
2.2-HEAD.


S.

--
[EMAIL PROTECTED]http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF




smime.p7s
Description: S/MIME cryptographic signature

Add 2.2.4 to bugzilla

[Ruediger Pluem]

Hi,

could someone please add version 2.2.4 to the product Apache httpd-2 in 
bugzilla?
Are there any ideas how we can document / automate this as part of the release 
process?
This issue pops up regulary after each release.


Regards

Rüdiger

Re: ap_get_module_config() questions...

[David Wortham]

Drew,
 I can only respond to two of your questions (intelligently):

First, how do I return valuable information if there's a config error?

For example, if my config has the directive "MyFile conf/foo.txt" and
the file doesn't exist, how can I report this when I run httpd -t?



If the error can be detected during a directive-handler, simply returning a
non-NULL string will output the error string to STDERR and halt the startup
process.
If the error detection happens later during the server process, you will
have to take different actions, but you should use a function like
"ap_log_rerror(...)" to output the error description to the server's error
log (what you do beyond that is up to you... the module programmer).


Second, the documentation (er, at least http_config.h) suggest using

r->per_dir_config or s->module_config for the conf vector (first arg).
I can only get things to work if I pass cmd->server->module_config.  Is
this the same as s->module_config?  Is this a coding blunder?



To explicitly answer your question, they are the same thing, only with an
intermediate variable set to the "server* s".
Look at this page (at the very bottom):
http://modules.apache.org/doc/API.html#servconf
The example function creates its own "server* s" as a pointer to the server
(pointer) in the cmd_parms struct.  I believe this step was skipped over by
your documentation page.

Hope this helps,
Dave

Re: 2.2.4 windows binary w/ssl?

[Jorge Schrauwen]

On 1/11/07, Issac Goldstand <[EMAIL PROTECTED]> wrote:



> ./configure; make; make install
>
> We don't deposit a certificate today for Unix.  After considering
> this a bit
> more, I agree with jerenkrantz.
>
>
> True... if you don't enable mod_ssl by default and add a note in the
> conf file It should be rather safe to not include a cert. Pointing them
> to a docs or wiki guide/how to would be a good idea.

I'd agree if mod_ssl is disabled by default, but if it is, why are they
downloading the mod_ssl-enabled installer?

The "stupid user" issue you mention is a great answer here, but not good
enough to disabled mod_ssl by default if there are seperate SSL and
non-SSL installers.





Good point on this, it makes no sense to have mod_ssl disabled in the ssl
binary. My silly mistake.


--
~Jorge

Re: 2.2.4 windows binary w/ssl?

[Issac Goldstand]

Jorge Schrauwen wrote:
> 
> 
> On 1/10/07, *William A. Rowe, Jr.* <[EMAIL PROTECTED]
> > wrote:
> 
> Jorge Schrauwen wrote:
> > Do note that not all users that will chose the SSL package will
> know how
> > to correctly fill in the fields.
> 
> s/not all/a small minority of/
> 
> 
> Do not underestimate user stupidity ;) ok maybe the number won't be
> overly to large but I can sure see the post flooding in on the Apache BB's!

True, but Bill has a point.  If they can't fill in "Domain Name",
"Company Name (Optional)", "City", "State", "Country", then SSL install
is the least of their problems ;-)

Seriously, it's just an issue of us naming the fields well.

[snip]

> ./configure; make; make install
> 
> We don't deposit a certificate today for Unix.  After considering
> this a bit
> more, I agree with jerenkrantz.
> 
> 
> True... if you don't enable mod_ssl by default and add a note in the
> conf file It should be rather safe to not include a cert. Pointing them
> to a docs or wiki guide/how to would be a good idea.

I'd agree if mod_ssl is disabled by default, but if it is, why are they
downloading the mod_ssl-enabled installer?

The "stupid user" issue you mention is a great answer here, but not good
enough to disabled mod_ssl by default if there are seperate SSL and
non-SSL installers.

  Issac

Re: 2.2.4 windows binary w/ssl?

[Issac Goldstand]

William A. Rowe, Jr. wrote:
> Jorge Schrauwen wrote:
>> Do note that not all users that will chose the SSL package will know how
>> to correctly fill in the fields.
> 
> s/not all/a small minority of/
> 
> They can't figure out what Domain Name means, let's be serious :)
> 
>> On 1/10/07, *Issac Goldstand* <[EMAIL PROTECTED]
>> > wrote:
>>
>> I think the MSI should autogenerate a self-signed cert at least (last
>> thing we need is for people to deploy a static pre-distributed cert
>> which would make it that much easier to do man-in-the-middle attacks).
> 
> I agree, static keys are only for pure localhost-style examples, just a bad
> idea for something this flexible.  As far as a default selfsigned cert,
> I was thinking of using the server name they filled in already as it stands,
> and let them replace it with a worthwhile one.

You mean as the default entry, right?  It should be changeable (and
should affect the ServerName in the default SSL virtualhost, of course)

> 
>> Would be great if the MSI had a choice to use an existing cert, or
>> generate a new one with a user supplied DN (fill-in fields for CN, OU, O
>> , L, ST, C), and generated a self-signed cert with that + a .csr for
>> sending to a Trusted Third-Party for signing.
>>
>> Would also be great if there was some GUI for importing a signed cert
>> post-install, similar to the IIS wizard, but that's probably pushing it.
> 
> Well, there are dozens of utilities out there that do that, I'm not compelled
> in the least to add it to the httpd package.

As I said, that's probably pushing it :-)

> 
> Justin Erenkrantz wrote:
>> I'd prefer to just point them at the instructions for generating their
>> own key rather than us distributing a 'fake' one.  -- justin
> 
> ./configure; make; make install
> 
> We don't deposit a certificate today for Unix.  After considering this a bit
> more, I agree with jerenkrantz.

Didn't there used to be a make cert in the Apache 1.3 days?  I
distinctly remember having that option at some point, though it may have
been from a modified source, like an SRPM or something...

> At least, initially.  I'd rather see something out the door, with all the
> appropriate comments in the user community of the best way (in their opinion)
> to proceed.

IMHO, that's like saying that the MSI shouldn't install the windows
service for you, or modify the default .conf files to suit your install.

If you want to do it this way, distribute a binary .zip  If we're
putting it in a GUI installer that knows how to prepare the initial
environment, this should definitely be one of the things it does...

> 
> Then if we really believe the server install should do something to either
> help deposit a cert/key for their server, or a post-install command should
> be provided for this purpose, then we should ensure win and unix are offering
> the exact same facility.
> 

I'll look around for the make cert rule that I remember seeing.  Should
be very simple to do this for unix, assuming an openssl binary exists
and is on the path

  Issac