On 04 Jan 2017, at 8:37 PM, Jacob Champion <champio...@gmail.com> wrote:
>> Can you give us an example of this dead code? > > In modules/ alone (I haven't looked at server/ yet, and don't plan to today), > after ignoring build-related files and stripping the svn-diff context, there > are twenty *thousand* lines of diff between 2.4 and trunk. > > Now, here's the problem. I can't prove which parts of these are dead and > which aren't; I can't prove that *any* of it is dead, really. I only know > that there are twenty thousand lines of unreviewed code changes in modules/. > That's significant, IMO. I need to stop you there - none of this code is unreviewed. “CTR” means “commit then review”, it basically means “write the code, make sure it works and integrates properly, then commit it - an email will be sent to the project, and people review that diff". Either that code is uncontroversial and accepted as is, or it will be challenged. This review part isn’t a joke. People like Rüdiger Plüm will pick apart and judge every line, and you have to defend your changes. Some changes can take a long time to get right. This could mean polishing the code as provided, or removing it entirely and trying again. Then, if you want to get to v2.4, you have to pass RTC “review then commit”. The change is then reviewed again a second time, this time asking the question “will this break existing users in any way”. We don’t change ABI on any stable branch (ie v2.4 or below). > Here are three cherry-picked modules which, to me, seem to be in limbo. > Whether we consider this code "dead" or "sleeping" or "on temporary hiatus" > or "untouched because it's perfect already" is probably heavily subjective. > > 1) mod_policy > > 1300 lines, added in 2011, last meaningful code change in 2012, no tests that > I can find. (However, it does have public documentation.) That waits for v2.6. mod_policy is itself a set of tests. > 2) mod_serf > > 1100 lines, added in 2007, last meaningful code change in 2011, no tests, no > public documentation. > > 3) mod_apreq2 > > 1000 lines, added in 2011, no meaningful code changes since addition, no > tests, no documented public release of libapreq2 since 2010. (It does have > public documentation. And it seems like there's history here I don't > understand. Maybe it lives somewhere else and was being folded into httpd?) This is historical. When v2.4 got released, the changes in mod_serf and mod_apreq2 were deemed to be not ready enough for v2.4. When v2.4 got created mod_serf and mod_apreq2 were not brought forward. If they’re not ready now, the same thing can happen. > So, there's 3k of the 20k. And remember, my point was that we can fix what I > call "dead code" with good old fashioned legwork. I don't advocate trashing > trunk, and I don't think having "dead code" is a disaster or a stain on > anyone here. I just don't think it's appropriate to spin up an RC from trunk > as-is. Look for the discussion that occurred around November 2011 when v2.4 was released: http://smtp.grokbase.com/t/apache/dev/11bb6wswq2/branched-httpd-2-4-x We came to the same conclusion then. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
