Re: 2.4.38

[Moradhassel, Kavian]

On 2018-11-11, 3:44 PM, "Edwardo Garcia" 
mailto:wdgar...@gmail.com>> wrote:


On Fri, Nov 9, 2018 at 6:05 PM Barry Pollard 
mailto:barry_poll...@hotmail.com>> wrote:


 2/ it gives impression of immature and buggy software - this gives thoughts 
towards alternatives,  IRC shows many admins have no loyalty todays much of 
todays software (well, windows fanbois excepted.

Massively disagree. Frequent release to me give the impression of an actively 
maintained and evolving project. And there are a lot of changes in the HTTP 
space (HTTP/2, move to encryption, increased awareness on security...etc.).


That's contrary to how most see it, I held off replying to this thread because 
I wanted to put this out there, on our system admin group, which contains some 
491 members from 29 countries, and includes some of the rather well known ISP 
and Hosting providers that are a lot bigger than a few soho admins, we are 
talking  just one of them alone hosts over 1 million websites, as of midnight, 
143 replied,with 141 said they do consider a release often approach bad and 
have and will refuse to update unless a compelling in the wild creates reason 
to. the other 2 respondents said they don't care either way.
The mentioned dovecot in an earlier post is a classic example, we have for over 
10 years been annoyed at its releases most because its a rushed bugfix which 
breaks something else and the cycle continues, we have members still using 
versions several years old because they consider them more stable, its long 
been a pet peave,

So I would air on the side of caution before this release often kreeps in.
You only have to look at the past few attempts (scrapped versions) to release 
apache to see the dangers in rush rush rush attitude.


I think it’s dangerous to conflate speed with quality…these are two very 
different things, and I believe they should be evaluated completely separately. 
 It’s possible to have frequent releases with good or bad quality, and it’s 
possible to have quality releases on a rare or frequent schedule.  I also think 
we’ve all seen (or can easily find) open source projects that match any 
combination of these two measures.  So I don’t think it’s valid to conclude 
that one will necessarily lead to the other.

An important principle of software development is that smaller changes are 
easier to understand, which means impacts are easier to predict.  This is true 
even for a project as big and with as varied usage as httpd (although note that 
“easier” != “easy”), and more frequent releases will, generally speaking, 
contain fewer and smaller changes.  When releases are months or years apart, 
it’s too easy to start throwing in everything *and* the kitchen sink…but this 
is more likely to lead to problems because you end up with bigger changes in 
every release.

And note that “frequent” doesn’t have to mean “rush”…the opposite can in fact 
be true.  If a developer knows that there are many opportunities to deliver a 
feature, they can feel less pressure to rush something into a release when it 
isn’t ready…but if releases are months or years apart, that’s when developers 
might rush things a little to get on the release train.

I think it’s important to look at each development community and their track 
record, rather than making broad generalizations.  A community that values both 
schedule and quality will make smart choices like dropping a feature from a 
release if it’s not ready for prime time.  I’m a relative newcomer to this 
list, but I’ve seen a few release cycles now, and I don’t think anyone is 
trying to put out a rushed and incomplete product.  And the “scrapped versions” 
used above as an example of rushing are actually great examples of the 
validation process doing its job and preventing delivery of releases that were 
not ready…I think these are evidence of the community indeed erring on the side 
of caution and not sacrificing quality to meet a schedule.

Just my $0.02. :-)

Re: 2.4.38

[Moradhassel, Kavian]

+1 (as one of the 99.99%)

In particular: "I'd prefer frequent releases and honest changelogs."


-Original Message-
From: Niklas Edmundsson 
Reply-To: "dev@httpd.apache.org" 
Date: Friday, November 9, 2018 at 8:10 AM
To: "dev@httpd.apache.org" 
Subject: [**EXTERNAL**] Re: 2.4.38


I usually don't like top-posts, but I just want to say that I agree 
completely with everything Barry stated below.

If you as an admin want an easy life, use the distro version.

If you have good reasons to build yourself simply suck it up and 
accept the maintenance pain (which it is, since you need to cater for 
updating all the dependencies as well if you want all the latest in 
features/fixes). And do read the release notes and upgrade only when 
there is a need.

Btw, regular releases increases the chance of distros picking up a 
somewhat current version with known fixes when they roll a new distro 
release.

I'd prefer frequent releases and honest changelogs. I'm more scared by 
projects that have no releases, since that tends to show dead 
development or some kind of idealistic view that software can be 
"finished" and not needing any more work done on it...

On Fri, 9 Nov 2018, Barry Pollard wrote:

>
>
> Disagree. My 2 cents as a watcher, administrator and user:
>
> 1/ they have better things to do
>
> Then don’t take the release! If a release contains security patches (so they 
> should take it), then I don’t see how hiding the issue by holding back the 
> release helps.
>
> 2/ it gives impression of immature and buggy software - this gives thoughts 
> towards alternatives,  IRC shows many admins have no loyalty todays much of 
> todays software (well, windows fanbois excepted.
>
> Massively disagree. Frequent release to me give the impression of an actively 
> maintained and evolving project. And there are a lot of changes in the HTTP 
> space (HTTP/2, move to encryption, increased awareness on security...etc.).
>
> 3/ As a consequence of 1 & 2, they will not upgrade, this might be trivial 
> for little thigs, but when a nasty bug comes out, this is what comes to mind" 
>  oh fsck it, we just upgraded httpd  last week, screw it, we'll wait" - they 
> get bitten, CIOs demand heads, remaining souls dump httpd and install nginx 
> or some other alternative
>
> Discussed above. And nginx releases monthly (http://nginx.org/en/CHANGES) 
> which I’d be happy if Apache HTTPD moved to.
>
> 4/ dont be fooled into thinking  its the package managers role, many networks 
> run on RedHat EL, SuseEL, and debian, but far from all - and even those 
> distro package maintainers get sick to F'n death of it after a while and skip 
> updates.
>
> I do wish Apache would run its own “official” repo to make upgrading to 
> latest easier. Don’t have the expertise to help with this and understand it 
> was done in the past and given up due to lack of people who did but still 
> think it’s a shame we don’t. I think this is an area nginx does stand out. 
> Upgrading Nginx is often as simple as “yum update” or “apt-get”. They even 
> run a repo for their mainline version for those that want to be bleeding edge.
>
> Do not be delusional - this has happened many times before.
>
> I give you dovecot as example, it wasnt that long ago a new release was 
> coming out weekly, sometimes only a few days apart, people get sick of 
> updating, some people are still today running versions a year old because of 
> it, I know of a few who moved to "courier", an oldy but a goody.
>
> And some people are still running Apache Httpd 2.2 or 2.4.6. I don’t think 
> that’s anything to do with the frequency of releases.
>
> The release often mentality might be good for a new nurturing project, but 
> that is not httpd.
>
> System admins want stability.
>
> Maybe, but that’s not the world we live in. And others want features and we 
> shouldn’t give the impression Httpd is legacy because it lacks the features 
> other web servers may have. Stay on packages managed version of 2.4.6 if you 
> want and just take the security updates that your package manager is 
> responsible to include.
>


/Nikke
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se  | ni...@acc.umu.se
---
  If life had a vomit meter, we'd be off the scale.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

RE: building 2.4.33 with apr < 1.5

[Moradhassel, Kavian]

Thanks for the quick response and workaround!

Kav Moradhassel | Ciena
kmora...@ciena.com | 385 Terry Fox Drive | Ottawa, ON, K2K 0L1  Canada

-Original Message-
From: Eric Covener [mailto:cove...@gmail.com] 
Sent: March 24, 2018 10:50 AM
To: Apache HTTP Server Development List <dev@httpd.apache.org>
Subject: Re: building 2.4.33 with apr < 1.5

On Sat, Mar 24, 2018 at 10:41 AM, Moradhassel, Kavian
<kmora...@ciena.com> wrote:
> Hello,
>
>
>
> When building the new 2.4.33 release on one of the RHEL-based distributions
> (Oracle Linux 7 in my case, but I think this would also happen on RHEL 7 and
> CentOS 7), I see this warning:
>
>
>
> mod_remoteip.c: In function ‘remoteip_sockaddr_compat’:
>
> mod_remoteip.c:329:5: warning: implicit declaration of function
> ‘apr_sockaddr_is_wildcard’ [-Wimplicit-function-declaration]
>
>  if (apr_sockaddr_is_wildcard(addr1) &&
>
>  ^
>
>
>
> And at runtime, I get this error when I try to load mod_remoteip:
>
>
>
> Cannot load modules/mod_remoteip.so into server:
> /opt/httpd/modules/mod_remoteip.so: undefined symbol:
> apr_sockaddr_is_wildcard
>
>
>
> A little googling tells me that apr_sockaddr_is_wildcard was adding in apr
> 1.5, but the apr version in RHEL/CentOS/etc. 7 is 1.4.8.
>
>
>
> Is there any way to work around this in the build, or do I have to build my
> own apr?
>

Looks inadvertent, sorry for the trouble.   Thanks for the report.

I suggest patching your mod_remoteip to make a local copy of that
little routine from APR:

http://people.apache.org/~covener/patches/remoteip-apr14.diff

I assume the workaround will not be necessary in any subsequent release.


>
>
> Thanks,
>
>
>
> Kav Moradhassel | Ciena
>
> kmora...@ciena.com | 385 Terry Fox Drive | Ottawa, ON, K2K 0L1  Canada
>
>



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

building 2.4.33 with apr < 1.5

[Moradhassel, Kavian]

Hello,

When building the new 2.4.33 release on one of the RHEL-based distributions 
(Oracle Linux 7 in my case, but I think this would also happen on RHEL 7 and 
CentOS 7), I see this warning:

mod_remoteip.c: In function 'remoteip_sockaddr_compat':
mod_remoteip.c:329:5: warning: implicit declaration of function 
'apr_sockaddr_is_wildcard' [-Wimplicit-function-declaration]
 if (apr_sockaddr_is_wildcard(addr1) &&
 ^

And at runtime, I get this error when I try to load mod_remoteip:

Cannot load modules/mod_remoteip.so into server: 
/opt/httpd/modules/mod_remoteip.so: undefined symbol: apr_sockaddr_is_wildcard

A little googling tells me that apr_sockaddr_is_wildcard was adding in apr 1.5, 
but the apr version in RHEL/CentOS/etc. 7 is 1.4.8.

Is there any way to work around this in the build, or do I have to build my own 
apr?

Thanks,

Kav Moradhassel | Ciena
kmora...@ciena.com | 385 Terry Fox Drive | Ottawa, 
ON, K2K 0L1  Canada

RE: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

[Moradhassel, Kavian]

Thanks!  That’s exactly the kind of ballpark I was hoping to hear. ☺


From: William A Rowe Jr [mailto:wr...@rowe-clan.net]
Sent: Tuesday, June 27, 2017 1:15 PM
To: httpd <dev@httpd.apache.org>
Subject: RE: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS



On Jun 27, 2017 12:08 PM, "Moradhassel, Kavian" 
<kmora...@ciena.com<mailto:kmora...@ciena.com>> wrote:
Did this discussion result in a decision to provide a fix for the bug in 2.4.26 
and plan for a 2.4.27 soon?  I'm wondering if I should be waiting for a 2.4.27 
in the next handful of weeks, or if I should just accept that 2.4.26 has a bug 
that we need to work around...

We don't generally try to predict our release schedule, when it's baked we 
publish a release.

But Jim and Jacob are furiously updating the test framework as you were asking 
your question, so I'm guessing the group will be working to release this fix 
just as soon as it is agreed upon, within a week or few.

RE: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

[Moradhassel, Kavian]

Did this discussion result in a decision to provide a fix for the bug in 2.4.26 
and plan for a 2.4.27 soon?  I'm wondering if I should be waiting for a 2.4.27 
in the next handful of weeks, or if I should just accept that 2.4.26 has a bug 
that we need to work around...

Thanks!


-Original Message-
From: William A Rowe Jr [mailto:wr...@rowe-clan.net] 
Sent: Tuesday, June 20, 2017 1:00 PM
To: httpd 
Subject: Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

On Tue, Jun 20, 2017 at 11:17 AM, Jacob Champion  wrote:
> On 06/20/2017 09:16 AM, William A Rowe Jr wrote:
>>
>> It's released into the wild, what is done is done.
>
>
> Of course. But having it in the wild for three days is different than having
> it in the wild for six months.

Unless you are classifying this a security fix, it may prove to be
a less popular update given what we announced as fixed in 2.4.26.
The same isn't expected for 2.4.27, since some users prioritize
security updates and let others sit for a while, or undergo added
scrutiny for non-critical updates.

In any case, it will be in the wild for >3 days. It's at five days and
counting, if you tag and roll today. Vote is 72 hrs long, and we
always give our mirrors a day to catch up with us.

You must presume it is in the wild, and shortening the exposure
by a matter of days isn't significant. It just needs the appropriate
clear note in CHANGES with 2.4.27 so that users are prepared
for the change (or reversion).