Re: Status for 2.4.20

[Noel Butler]

On 26/03/2016 22:54, Reindl Harald wrote:


*yawn*


grow up!

especially with your off-list hate-mails while block responses



off-list hate mails? The message was pretty clear you emailed me asking 
me never to reply to any of your posts some time ago, I emailed you 
reminding you that works both fscking ways and if you didnt like that 
hell will be unleashed upon you.



also, the DNSBL blacklisting on you for your antics of past 2+ years or 
so still stands given what I've witnessed even in recent times. If you 
are going to be abusive, and  blackmailing people, you have to live with 
reactions to your actions, it is only appropriate a DNSBL "tell" people 
why a host is blocked, just proudly doing my job :)


if you were not a complete arsehole, none of those list moderations, 
bannings and so on would have occurred, but seems like you will never 
change, consider this the last time i reply to you on this list, and 
thank you for re-justifying the DNSBL listing.


happy easter

--
If you have the urge to reply to all rather than reply to list, you best
first read  http://members.ausics.net/qwerty/

Re: Status for 2.4.20

[Daniel Ruggeri]

On 3/23/2016 7:27 AM, Jim Jagielski wrote:
> Release Often is hardly a Bad Thing, at least IMHO. When the
> time is right for a release, then we release. It seemed a
> good time, again IMHO.

Kinda late to the party, but shouldn't what's committed to a stable
branch _always_ be ready to release?



Just my .02 on the side conversation. As a sysadmin, I have no strong
preference for release often versus release seldom... just so long as
what is released is stable and won't break my stuff.
At $dayjob where I have to answer to regulatory and audit authorities,
there have been plenty of releases of various software platforms that I
have chosen not to pursue because they don't address anything I need to
worry about. No harm done.

So, my stance as a sysadmin (and probably a fairly common stance, I'd
guess) can be summarized as:
If there's a bug fix for a problem I'm seeing, I'd really like the
release sooner rather than later. On the other hand, if there's a
security fix, I need it released immediately. On yet another hand
(because it seems I have three), if the release has nothing I care
about... then I don't care.
But whatever happens, don't break my configs :-)



As an even further side note... after following this dev list
(community) as long as I have, I'd happily put an httpd 2.4.nightly
against just about any other released software. I can't think of a
single case where something got *committed* to 2.4 that would break my
configs let alone something that got formally released. Indeed, the few
thousand httpd servers I run haven't been harmed by a release in all of
my time as an admin (1.3, 2.0 and 2.4 alike). Our release process is,
indeed, pretty damn good. So whether we release often or release seldom,
we can at least hold our head high while we do it.

-- 
Daniel Ruggeri

Re: svn commit: r1736683 - /httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml

[Marion & Christophe JAILLET]

As far as I've seen, directive names used within the corresponding 
 bloc do not have a link to themselves.

That's why I have removed some in this commit.

In the same commit, I've also added some missing module= for some other 
directives in order to keep the link to them.


As an example, in this commit, you can find:

+AuthLDAPSubGroupAttribute directive identifies the
+labels of group members and the AuthLDAPGroupAttribute

No module= for AuthLDAPSubGroupAttribute but one for 
AuthLDAPGroupAttribute, because we are in the AuthLDAPSubGroupAttribute 
 bloc.



I've never seen this "rule" written anywhere, but it looks a quite 
classical way to do within the online doc.
I personally find it logical and it helps, IMHO, to quickly see if the 
explanation we are reading it about the current directive or if it is 
related to something else, which can be found somewhere else.


If module= everywhere is the preferred way, that's good for me and will 
update accordingly.



BTW, I will backport port these changes during the WE but I'm in the 
process to synch 2.4 and trunk for this given file. Started but not 
finished yet.


CJ



Le 26/03/2016 13:51, Eric Covener a écrit :

On Sat, Mar 26, 2016 at 3:51 AM,   wrote:

-module="mod_authnz_ldap">AuthLDAPBindPassword if you
+>AuthLDAPBindPassword if you
  absolutely need them to search the directory.


I am in the habit of always adding module= so we get the directive as
a hyperlink.  Is there a rationale for removing them?

Re: Status for 2.4.20

[Reindl Harald]

Am 26.03.2016 um 04:44 schrieb Noel Butler:

On 26/03/2016 13:32, Reindl Harald wrote:

Am 26.03.2016 um 04:13 schrieb Noel Butler:

On 25/03/2016 19:52, Graham Leggett wrote:

On 23 Mar 2016, at 1:58 PM, Noel Butler  wrote:


as stated previously, this shit will happen when certain people push
with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched by any
pending release, so lets get house in order  S T A B L E , then worry
about releases, jesus christ, we are not ubuntu or redhat with set
programs to release every 3 or 6 months regardless if shit is ready
or not…..


It sounds like you’re making drama where there is none.


sounds like you only look at this from one perspective, and thats not of
the users, especially, the larger users.


if it has no relevant bugfixes for you - just don't upgrade - so what
why should others wait for probably relevant fixes longer just because
you are annoyed by an update nobody is forcing you to install?


*yawn*


grow up!

especially with your off-list hate-mails while block responses



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1736683 - /httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml

[Eric Covener]

On Sat, Mar 26, 2016 at 3:51 AM,   wrote:
> -module="mod_authnz_ldap">AuthLDAPBindPassword if you
> +>AuthLDAPBindPassword if you
>  absolutely need them to search the directory.


I am in the habit of always adding module= so we get the directive as
a hyperlink.  Is there a rationale for removing them?

-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1736687 - /httpd/httpd/trunk/docs/manual/howto/index.html.en

[Luca Toscano]

Hi Stefan!

2016-03-26 9:34 GMT+01:00 Stefan Eissing :

> We should backport this howto as well.
>

Yes definitely, together with the latest version of mod_http2 docs. I was
waiting for the new release, but we can anticipate!

Luca

Re: svn commit: r1736687 - /httpd/httpd/trunk/docs/manual/howto/index.html.en

[Stefan Eissing]

We should backport this howto as well. 

> Am 26.03.2016 um 09:21 schrieb elu...@apache.org:
> 
> Author: elukey
> Date: Sat Mar 26 08:21:40 2016
> New Revision: 1736687
> 
> URL: http://svn.apache.org/viewvc?rev=1736687=rev
> Log:
> documentation rebuild
> 
> Modified:
>httpd/httpd/trunk/docs/manual/howto/index.html.en
> 
> Modified: httpd/httpd/trunk/docs/manual/howto/index.html.en
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/howto/index.html.en?rev=1736687=1736686=1736687=diff
> ==
> --- httpd/httpd/trunk/docs/manual/howto/index.html.en (original)
> +++ httpd/httpd/trunk/docs/manual/howto/index.html.en Sat Mar 26 08:21:40 2016
> @@ -88,6 +88,20 @@
> 
> 
> 
> +  HTTP/2 with httpd
> +  
> +  HTTP/2 is the evolution of the world's most successful application 
> layer protocol, HTTP. 
> +It focuses on making more efficient use of network resources without 
> changing the semantis of HTTP.
> +This guide explains how HTTP/2 is implemented in httpd, showing 
> basic configurations tips and 
> +best practices.
> +  
> +
> +See: HTTP/2 guide
> +  
> +
> +
> +
> +
>   Introduction to Server Side Includes
>   
> SSI (Server Side Includes) are directives that are placed in
> 
>