On 20 Jan 2017, at 4:29 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>> Right now, there are a number of gratuitous breaking changes on trunk >>> that change binary ABI. I'm considering a trunk fork to preserve these >>> changes (branches/3.x-future/?) and reverting every change to trunk/ >>> which was otherwise a no-op. Namespace, decoration, anything that >>> prevents a user from loading a 2.4.x module in 2.next. And then we >>> can look at what is a valid reason to take us to 3.0. >> >> -1 (veto). > > To be clear, procedural decisions can't be vetoed. But specific code > changes can be vetoed. > > I can veto and revert each individual commit on trunk which breaks the > API or ABI in an unnecessary manner, pointing at that specific > breakage, and invite the committer to propose the change using the > existing interfaces. This would be an abuse of the veto mechanism - the veto is to protect the project, not force other people to do work on your behalf, whether “invited” to or not. In a case like this, what you’d be expected to do is write and commit patches that fixed any cases you felt was unnecessary yourself, and have those patches reviewed by the rest of the project in the normal way. > In light of your objection, I won't proceed with a preservation > branch, but take the veto knife directly to trunk. As per our rules a veto requires a technical justification. Breaking changes are allowed on trunk, and so the fact the change is breaking is not in itself sufficient justification for a veto. >> As you are well aware, the jump from v2.0 to v2.2, from v2.2 to v2.4, and >> the jump from v2.4 to v2.6 involves breaking changes, and this is a well >> established and stable pattern that is well understood by our end users. The >> “problem” you’re trying to solve does not exist. > > There is nothing in httpd which is stable, and 2.4.x certainly hasn't > been well established. Not even 50% of Apache httpd deployments use > 2.4.x almost four years later, and 2.4.25 looks so considerably > different than 2.4.1 that it cannot be called a maintenance branch. It > is impossible to identify from "2.4" what point in its evolution is > causing a reported issue without knowing the subversion. A handful of > 2.4.x releases walked out the door without some significant regression > - not a proud track record. So this problem which I'm trying to solve > is clearly present. I disagree, sorry. > Finally the fact that httpd's last release was Feb '12 indicates to me > a project at risk. The last releases occurred in Dec ’16 and Jan ’17 respectively. If you want to see trunk released, let’s branch and release v2.5.x in anticipation of v2.6.x. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
