On Thu, Jan 19, 2017 at 6:29 AM, Jim Jagielski <j...@jagunet.com> wrote: > >> On Jan 18, 2017, at 8:35 PM, Eric Covener <cove...@gmail.com> wrote: >> >> On Wed, Jan 18, 2017 at 6:12 PM, William A Rowe Jr <wr...@rowe-clan.net> >> wrote: >>> I'm wondering if there is anyone interested in a regression-fix-only 2.4.26 >>> that >>> finally proves to be a workable upgrade for all httpd users? >> >> It sounds reasonable to me, but I think it's a bit of an oversell -- >> It's just going to be a little bit of stabilization. > > Agreed, but what did you expect? If anyone other than Bill > would have proposed this, he would have complained that > having such frequent releases is bad, etc...
Jim, are you really going to start ad hominem attacks again on dev? I thought Eric asked nicely enough for this to desist. Don't put words into my mouth. If you want to quote one of my posts, I don't think you will find a single post where I suggested that there is an issue with the frequency of releases, but please feel free. You'll find posts stating that the next release should contain 'X' where 'X' was generally a security or regression fix that had not received sufficient attention to backport. I used to be of the mind that changing from 2.4 to 2.6 was some radical change that our users would resist. I've come to the conclusion that the pace of adoption of 2.0 from 1.3, or 2.2 from 2.0, or now from 2.2 to 2.4... little of this had to do with the major or minor reversion. Users simply don't update, except as provided by their environmental provider (some OS distro or cpanel or other deployment schema.) If anything, Bill and others have recently argued that version numbers, even minor, and major, are cheap. We should use them IMO. > Here's the real issue, as I see it. If there have been "recent > breakages" it is not due to the release process, but rather > the *testing* process. That is, not enough people testing > 2.4-HEAD until we actually get close to a release. The idea > should be that 2.4-HEAD is ALWAYS in a releasable and "runnable" > state, it being RTC after all. My perception is that many enhancements get rammed into the maintenance branch in the final days of a candidate because new features are neat, instead of applying them weeks ahead of a tag and ferreting out breakage across the breadth of architectures and deployments that httpd enjoys. There are three reviewers. If things are going into a release they either aren't getting sufficient review by those three people, or three people are inadequate, or more likely... Our testing process can never and will never capture 10% of the various ways different developers and users have deployed and customized their httpd environment, as is illustrated in our bug tracker. But having some approachable httpd.a.o/test/ pages that get mentioned in our 'reporting bugs' pages might help encourage users with more novel schemas to propose some test case patches to our test framework? That would increase coverage, it will always remain a fraction of the anticipated and unexpected use cases. > This is only, clearly, an attempt by Bill to commandeer the > 2.4 release process, nothing more. Again, anyone is free > to RM... there is no need to fabricate reasons to do so. > If Bill wants to do a quick 2.4.26 with the current fixes > then sure, why not. Especially if it will be "one we think is > good", and we can pat Bill on the back for a job well done. But the onus should not be on Bill's Releases to win some feature-frozen and reduced-breakage/regression-fixing packages for our users, while users expect Jim's Releases to offer the newest (and potentially/eventually regression inducing) features and enhancements. You've put restated the argument again this month that if we don't enhance and add features, we will lose user share to another web server. I've restated the argument again this month that unnecessary regressions cost us user share. You restate above that a lack of testing causes regressions, I am restating that adding features to maintenance releases causes regressions. This isn't my effort to commandeer the release process, it is actually my third distinct proposal in a month to find some major.minor.subversion schema which would be respected and honored by the entire PMC. We can have a war of the releases, that seems to be what you want. I would rather see new committers and pmc members jump into the role of RM - one that doesn't require years of dev list history to anticipate whether the community will accept a release tag at a particular point in time. It isn't about Bill and Jim, Jim. It is about a community of coders, who aren't listening well to the needs of one segment or another of our users and consumers, and our use the designated 'maintenance' release as a substitute for our shipping any new releases.
