> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> It is safer. It is incredibly time consuming to effectively perform
> a full audit of the state of trunk vs current. If we were to take this
> approach, it seems necessary to revert all of the unaccepted
> changes that live on trunk. E.g. rename trunk/ to scratchpad/
> and fork 2.4.x as trunk/ - 2.5.x.
You state that "It is incredibly time consuming to effectively perform a
full audit of the state of trunk vs current" which would imply that trunk
deviates so significantly from current that we have no idea of where trunk is.
You are against a full audit because it is time consuming? That those who
wish that the QA aspects of trunk, *as a releasable branch which
has been under RTC for year* be verified are somehow
obstructionists? I think it's called due diligence.
> If this is in fact the state of httpd, that trunk/ can no longer be
> released, that committers and PMC performed no oversight of
> the repository, it seems like a stunning indictment of all of us,
> and the obvious reaction by ASF board would be to strip the
> committer privileges of all, dissolve the PMC, and use the
> metric of trunk commit -> dev@ feedback to repopulate the
> project with those who demonstrated some participation over
> the trunk/ review process within the past seven years. Every
> ex-officer of the project and foundation would be ineligible to
> participate as a PMC or committer due to willful negligence
> for any such a restart, myself included.
Sorry Bill, but that's not right. trunk is not a "branch" that directly leads
to a releasable branch. Its simply not. It was not intended to
be. You cannot now claim that any inability, or concern, about
releasing a RTC "sandbox" somehow implies your conclusion.