Re: 2.4.38
On Sun, Nov 11, 2018 at 3:54 PM Barry Pollard wrote: > 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’m assuming it’s a given that httpd should only release when ready to. I > don’t think any of the release-often advocates are suggesting taking less > care with releases or releasing untested code. My question is would any > more testing go on if we did release less frequently? On one side I get the > argument that more time between releases theoretically allows for more > testing time, but I question whether anyone would use that time for that? > My experience of software development (outside of httpd) suggests not. > Something that is specific to httpd as opposed to other projects... Many projects today follow the -RC1 -RC2 -RC3 ... final release pattern. HTTPD project as a collection of patches always agreed that once a tarball of source code files was assembled, that the number assigned to it would never change. There would be no post-release changes to that tarball to designate it as a release. Therefore in the 2.4.x timeline, roughly 1/3 of the version numbers were "duds". Nobody observed these outside of the dev@ list and the specific http://httpd.apache.org/dev/ space (and associated development tags in subversion), because these aren't announced until they are accepted. This simply does not differ from other major project's success/failure rate of their -RC1, -RC2 attempts at collecting an "acceptable" release. Only the naming convention differs.
Re: 2.4.38
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
> The list is > included below and yet, I forgot to include it: 1-: clang static analyser 2-: lldb 3-: klee 4-: safecode 5-: googletest 6-: valgrind (with gdb and kgdb plugins) 7-: coccinelle 8-: sparse 9-: kcov & gcov 10-: kasan & ubsan 11-: kernel memleaks detectors 12-: linux kernel selftests 13-: kernelci 14-: oprofile 15-: Selenium WebDriver and its IDE 16-: Systemtap 17-: . goal of that is to test end to end from top to bottom of all the software stack at any granularity. Alain
Re: 2.4.38
> > 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’m assuming it’s a given that httpd should only release when ready > to. I don’t think any of the release-often advocates are suggesting > taking less care with releases or releasing untested code. My > question is would any more testing go on if we did release less > frequently? On one side I get the argument that more time between > releases theoretically allows for more testing time, but I question > whether anyone would use that time for that? My experience of > software development (outside of httpd) suggests not. To provide a 0.02$ answer to that question, last night, I went around and looked for the many amount of tools that can be used to take care of the continuous integration & continuous delivery, testing (both performance as well as debugging) and other assorted tools to help putting out the best releases of software as possible. The list is included below and include both userspace tools as well as Linux kernel tools (selftest, memleaks, kasan & ubsan...) The thing is, some software are famous for API and / or ABI breakage despite their release cycles (short like 2 weeks to a month, long like yearly releases). Which software? that is irrelevant. The few reasons I am working on that at the moment is purely for my own big@ss selfish benefits in that I was / am working for a long time as a computer tech, sysadmin, software developer and testing and I became irritated enough time by quality issues in build-it yourself distros (gentoo, funtoo, LFS+BLFS...among them, LFS+BLFS is the best quality one so far) that I want to put up a home server which will do nothing but testing using the toolset and releasing distributions images (kernel + userspace selected for various tasks, workstation or server). Side benefit is that, as soon as breakage happen (say, after a particular commit or something), I get to know immediately and report; optionally, provide a patch (which is my intended goal, short to medium-term). > Saying that, the releases do take effort and do take time to test, so > I don’t think httpd is ever going to be a fully automated “DevOps” > process that is comfortable releasing multiple times per day. As I > mentioned previous nginx seems to release once a month and that seems > about right to me but others may have a different opinion. Perhaps it > would be good to clarify that to make sure we are all on the same > understanding as to what to goal here is? Look at it this way. It is popular in software company to use scrum methodology and cut a release (internal or external) every two weeks, or, on a monthly basis with frequent new features but it can and does happen that a particular scrum cycle can be used for refactoring / bug fixes purpose with no new features added (I can't provide any more details than that). In many of those companies (those existing since a long time), it took some massive effort to migrate to a scrum based methodology from a waterfall methodology. It is my impression (and as always, I could be wrong), a similar pain look like it happen here. > Nonetheless scrapping a release is seen as a bad thing, as your > comment suggests so perhaps that needs to be addressed one way or > another. I won't comment on scrapping a release (number) but I do hope that the system I'm working on will prove useful when it is done and I can make it available. My constraints is that I can't provide any deadline for it given that my medical care now right now is tying up between 15 and 25 hours per weeks of work (medical consult, homework, helping with the number of differential diagnoses and some medical literature review to offload my medical team) for the next few years. > In summary I can understand why you got the stats you did, but I > still believe there are compelling reasons to release more frequently > (within reason). ultimately, I think frequent releases will prove useful but before, there is some pain needing to be overcome first. Alain
Re: 2.4.38
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 Interesting statistics, thanks for sharing. I can’t really argue with those stats but will make an attempt anyway ;-) Not to argue with the stats themselves, but to argue what they mean (lies, damned lies and statistics and all that). I am sure some sysadmins would prefer we had no releases at all. Releases are effort after all. But that also means there are no security issues to address or new features for website owners to take advantage of and I don’t think that will ever be the case for a, still evolving technology like a web server. Not addressing both of these, risks Apache httpd falling behind competitors - which I personally think is a bigger risk than users leaving httpd because it releases too often. For those that want stability over features the packaged versions managed by the various Linux distros seems to be the perfect solution. They get timely security patches but don’t have as much risk of breaking things as only take those security patches and not the feature changes. Why is that not the best option for these users that responded? This still allows the rest of us that one them, new features. As I said earlier, holding off releases of security issues because we don’t want to do frequent releases just seems non-sensical to me, so if staying with vendor-packaged versions, it makes little difference how many releases httpd do except they get security fixes earlier with frequent releases. And that can only be a good thing IMHO, even if it does create work. and have and will refuse to update unless a compelling in the wild creates reason to. That to me should always be the reason for upgrading. I don’t think it’s necessary to take every update a vendor publishes - unless it includes security fixes, in which case they should strongly be considered depending on whether those security issues affect your usage of the application (which is admittedly sometimes more difficult to figure out than just taking the patch!). As I say staying with Linux vendor packaged-version means you take the security patches only (and may take nothing from several httpd releases in a row if there are no security patches). Though, on the flip side, I do think keeping software reasonably up to date is better or you’re in for a shock when you inevitably do upgrade. 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’m assuming it’s a given that httpd should only release when ready to. I don’t think any of the release-often advocates are suggesting taking less care with releases or releasing untested code. My question is would any more testing go on if we did release less frequently? On one side I get the argument that more time between releases theoretically allows for more testing time, but I question whether anyone would use that time for that? My experience of software development (outside of httpd) suggests not. Additionally it’s very often the case that small releases reduce the risk (as little is changing) and reduce the time to fix when something does go wrong (as little has changed and it’s often fresher in the developers mind). That’s not to say that bugs don’t go for several versions without being noticed, but at least major one should be seen quickly. Saying that, the releases do take effort and do take time to test, so I don’t think httpd is ever going to be a fully automated “DevOps” process that is comfortable releasing multiple times per day. As I mentioned previous nginx seems to release once a month and that seems about right to me but others may have a different opinion. Perhaps it would be good to clarify that to make sure we are all on the same understanding as to what to goal here is? On your last point, I do think the perception of scrapping a version is bad, even if it is actually healthy for software to do this if they are not comfortable releasing it. Version numbering is cheap after all, so other than the perception there is little lost with this approach. And the alternative of being scared to scrap a version and pushing ahead with a buggy release is far worse. Nonetheless scrapping a release is seen as a bad thing, as your comment suggests so perhaps that needs to be addressed one way or another. I do think that if httpd went with release candidate versioning, like others do, it would that improve the perception here. So 2.4.38-RC1 is proposed and tested, then if bugs are found it goes to
Re: 2.4.38
On Fri, Nov 9, 2018 at 6:05 PM Barry Pollard 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.
Re: 2.4.38
> On Nov 9, 2018, at 2:54 PM, Graham Leggett wrote: > > On 09 Nov 2018, at 17:51, Stefan Eissing wrote: > >> So, the chance is high that releases we do will work for most of you. >> AND the chance is high that releases might break something for some of you >> (hopefully a few). > > The chance is very low that releases might break something, and this is done > by design. > > The place where we might break something is trunk. Before you get anywhere > near a release, you have to carve out your change, and propose it for > backport to a release branch. This is the first check. Two other people will > then check your backport, and if problems are found you’ll be asked to fix > it. That’s the second and third check. Then a release is proposed. A tarball > is cut, and a whole lot of new people do checks on the tarball. In the case > of 2.4.37, this was the fourth, fifth, sixth, seventh, eighth, ninth, tenth > and eleventh check for the 8 people who tested it. > > This strategy has worked very well for us since the 1990s, and we must not > understate its importance. > If it ain't broke. :)
Re: 2.4.38
On Fri, Nov 9, 2018 at 2:04 PM Graham Leggett wrote: > On 09 Nov 2018, at 17:51, Stefan Eissing > wrote: > > > So, the chance is high that releases we do will work for most of you. > > AND the chance is high that releases might break something for some of > you (hopefully a few). > > The chance is very low that releases might break something, and this is > done by design. > > The place where we might break something is trunk. Before you get anywhere > near a release, you have to carve out your change, and propose it for > backport to a release branch. This is the first check. Two other people > will then check your backport, and if problems are found you’ll be asked to > fix it. That’s the second and third check. Then a release is proposed. A > tarball is cut, and a whole lot of new people do checks on the tarball. In > the case of 2.4.37, this was the fourth, fifth, sixth, seventh, eighth, > ninth, tenth and eleventh check for the 8 people who tested it. > > This strategy has worked very well for us since the 1990s, and we must not > understate its importance. Good summary, but it's inevitable, Stefan was pointing out that something is likely to break in a feature/enhancement release for *someone*. Not for the vast majority of users who have somewhat stock configurations, but for those with their own custom modules or filters or even build schemas that get touched when we add dependencies and change the influence (not necessarily the definition) of the directives. The goal is to make that number of cases as small as possible, as you've both pointed out. Thanks for the reminder/pointer to the rpm instructions.
Re: 2.4.38
On 09 Nov 2018, at 17:51, Stefan Eissing wrote: > So, the chance is high that releases we do will work for most of you. > AND the chance is high that releases might break something for some of you > (hopefully a few). The chance is very low that releases might break something, and this is done by design. The place where we might break something is trunk. Before you get anywhere near a release, you have to carve out your change, and propose it for backport to a release branch. This is the first check. Two other people will then check your backport, and if problems are found you’ll be asked to fix it. That’s the second and third check. Then a release is proposed. A tarball is cut, and a whole lot of new people do checks on the tarball. In the case of 2.4.37, this was the fourth, fifth, sixth, seventh, eighth, ninth, tenth and eleventh check for the 8 people who tested it. This strategy has worked very well for us since the 1990s, and we must not understate its importance. Regards, Graham —
Re: 2.4.38
On 09 Nov 2018, at 10:05, Barry Pollard wrote: > 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. If you want an RPM of the bleeding edge of either httpd or APR/APR-util, it’s a one-liner as documented here: https://httpd.apache.org/docs/2.4/platform/rpm.html Regards, Graham —
Re: 2.4.38
*to thank* (oh my) > Am 09.11.2018 um 16:51 schrieb Stefan Eissing : > > I would like all who replied in this thread for their feedback. It is good > to hear that many are looking forward to frequent releases, especially as > the field we are all working in continues to develop. > > Apache httpd is a server capable of many things, all configurable in various > ways and even extendable by modules beyond our control here. In short, the > combinations in which this software is used is beyond our capabilities to > verify absolutely. > > That makes it tricky, when bringing in "new stuff", not to break anything. > Because, frankly, before it breaks, we are not always aware that it was used > that way. (Would we be, we would have tried to fix is before release - > ideally). > > So, the chance is high that releases we do will work for most of you. > AND the chance is high that releases might break something for some of you > (hopefully a few). > > We can wiggle the probabilities by a range of activities: > - more test cases > - less new features > but we will never eliminate them. Complexity is too high. > > That is where distros play a crucial role, IMO, as they invest in > stabilization of the many products they integrate and, as a user, > you can select from a range of options depending on your willingness > to bleed vs. desire for stability. > > But people who directly use the product from us are as least as > important. I got a lot of feedback on HTTP/2 that way (read: you > found my mistakes) and the quality we have today would not have been > possible without that. Which benefits everyone. So, thank you! > > Cheers, > > Stefan > >> Am 09.11.2018 um 15:54 schrieb 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. >>> >
Re: 2.4.38
I would like all who replied in this thread for their feedback. It is good to hear that many are looking forward to frequent releases, especially as the field we are all working in continues to develop. Apache httpd is a server capable of many things, all configurable in various ways and even extendable by modules beyond our control here. In short, the combinations in which this software is used is beyond our capabilities to verify absolutely. That makes it tricky, when bringing in "new stuff", not to break anything. Because, frankly, before it breaks, we are not always aware that it was used that way. (Would we be, we would have tried to fix is before release - ideally). So, the chance is high that releases we do will work for most of you. AND the chance is high that releases might break something for some of you (hopefully a few). We can wiggle the probabilities by a range of activities: - more test cases - less new features but we will never eliminate them. Complexity is too high. That is where distros play a crucial role, IMO, as they invest in stabilization of the many products they integrate and, as a user, you can select from a range of options depending on your willingness to bleed vs. desire for stability. But people who directly use the product from us are as least as important. I got a lot of feedback on HTTP/2 that way (read: you found my mistakes) and the quality we have today would not have been possible without that. Which benefits everyone. So, thank you! Cheers, Stefan > Am 09.11.2018 um 15:54 schrieb 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 s
Re: 2.4.38
+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: 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: 2.4.38
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.
Re: 2.4.38
On Fri, Nov 09, 2018 at 02:15:07PM +1000, Noel Butler wrote: > even those distro package maintainers get sick to F'n death of it after > a while and skip updates. I do not see any reason I should get distinguished by it. Frequent version updates are even better for me. Petr
Re: 2.4.38
I’m all for this as well, because people want the new hotness. That said, for people downstream that have to support httpd, y’all are releasing really fast. I get it, and we haven’t really had any problems (minus a weird semaphore issue we haven’t tracked down yet), I’m noticing an increase of releases lately. Just curious what is the rush lately? Is this all a build up to 2.6 coming out or something else? > On Nov 8, 2018, at 3:11 AM, Stefan Eissing > wrote: > > >> Am 07.11.2018 um 16:15 schrieb Jim Jagielski : >> >> Now that we have a 2.4.37 out, one in which the number of enhancements and >> fixes and feature were limited, it makes sense to consider having a 2.4.38 >> release somewhat "soonish", esp considering the number of backports that >> lack only a single vote. >> >> Comments? > > I am all for it. And I have reasons! :-) > > 1. We are well on track to automate the whole thing nicely. We need some more > iterations to make it tight. This is easier done in short intervals. > 2. I think regular releases are good for the people here and motivate people > from outside to contribute. > 3. h2 and Let's Encrypt still get attention and there are some small > improvements I'd like to throw out there. Nothing serious, just would be nice. > > Cheers, > > Stefan Super off topic but this is one of the best communities I deal with in my day to day, even when y’all are mad you’re good to each other, means a lot to those of us that just need to follow the feed. Thank you all for that. Thanks, Cory McIntire Release Manager - EasyApache cPanel, L.L.C. smime.p7s Description: S/MIME cryptographic signature
Re: 2.4.38
On 08/11/2018 19:11, Stefan Eissing wrote: > 2. I think regular releases are good for the people here and motivate people > from outside to contribute. For people here.. what about the people not here, you know them, 99.9% of them, the system admins responsible for all those servers out there, they do not appreciate having to update shit every 2 weeks. 1/ they have better things to do 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) 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 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. 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. The release often mentality might be good for a new nurturing project, but that is not httpd. System admins want stability. flame away. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument
Re: 2.4.38
> Am 07.11.2018 um 16:15 schrieb Jim Jagielski : > > Now that we have a 2.4.37 out, one in which the number of enhancements and > fixes and feature were limited, it makes sense to consider having a 2.4.38 > release somewhat "soonish", esp considering the number of backports that lack > only a single vote. > > Comments? I am all for it. And I have reasons! :-) 1. We are well on track to automate the whole thing nicely. We need some more iterations to make it tight. This is easier done in short intervals. 2. I think regular releases are good for the people here and motivate people from outside to contribute. 3. h2 and Let's Encrypt still get attention and there are some small improvements I'd like to throw out there. Nothing serious, just would be nice. Cheers, Stefan
Re: 2.4.38
I like the idea. I even have a reminder in my calendar for Sunday titled "check if release is ready to roll" :-) I can RM again, even. -- Daniel Ruggeri On November 7, 2018 9:15:06 AM CST, Jim Jagielski wrote: >Now that we have a 2.4.37 out, one in which the number of enhancements >and fixes and feature were limited, it makes sense to consider having a >2.4.38 release somewhat "soonish", esp considering the number of >backports that lack only a single vote. > >Comments?
