Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

On Tue, Jan 3, 2017 at 7:04 PM, Noel Butler  wrote:
>
> On 03/01/2017 23:11, Jim Jagielski wrote:
>
> Back in the "old days" we used to provide complimentary builds
> for some OSs... I'm not saying we go back and do that necessarily,
> but maybe also providing easily consumable other formats when we
> do a release, as a "service" to the community might make a lot
> of sense.
>
>
> 2 years ago it was decided to stop the official -deps (despite they are 
> included in dev still)... now you want to bring it back? (you'd have to if 
> you're going to roll usable binary packages or your "community service" 
> re-built packages are going to be broken)

I don't think he said that. For years httpd shipped the compiled
current openssl, expat, pcre sources as a binary. There was no sources
package of these, although we did provide the .diff to get the
packages to build correctly.

Because HTTP/2 requires OpenSSL 1.0.2, that will have to be part of
most packages, including semi-modern Linux flavors.

PCRE[2] is unavoidable, and while libxml2 can sub in for libexpat, the
SVN project would rather we bound to libexpat for specific features
they rely on.


> Although I as many others here prefer to roll our own due to our configs, and 
> not having to deal with bloat, I can see this having a positive effect for 
> users of a couple of distros who when they release brand new releases, come 
> with antiquated junk thats outdated and stays outdated, to give those users a 
> choice of using a modern code set would be good, but requires long term 
> dedication.

Agreed - it simply has to land somewhere like /opt/apache/httpd/ or
whatnot, to disambiguate whatever the user builds for themself in
/usr/local/ and what the OS might provision in /usr/

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Noel Butler]

On 03/01/2017 23:11, Jim Jagielski wrote:

> Back in the "old days" we used to provide complimentary builds
> for some OSs... I'm not saying we go back and do that necessarily,
> but maybe also providing easily consumable other formats when we
> do a release, as a "service" to the community might make a lot
> of sense.

2 years ago it was decided to stop the official -deps (despite they are
included in dev still)... now you want to bring it back? (you'd have to
if you're going to roll usable binary packages or your "community
service" re-built packages are going to be broken) 

Although I as many others here prefer to roll our own due to our
configs, and not having to deal with bloat, I can see this having a
positive effect for users of a couple of distros who when they release
brand new releases, come with antiquated junk thats outdated and stays
outdated, to give those users a choice of using a modern code set would
be good, but requires long term dedication.

-- 
Kind Regard, 

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

signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/03/2017 06:07 AM, William A Rowe Jr wrote:

If trunk/ is a dead fork, it may be time for httpd to admit this, trash
it and re-fork trunk from 2.4.x branch.


I don't feel that trunk is a dead branch, but I do think there is dead 
code in trunk. The CTR policy contributes to that, IMO, but we can solve 
that problem with elbow grease. A re-fork feels like overkill...


--Jacob

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/02/2017 04:11 PM, William A Rowe Jr wrote:

So far, discussions are polarized on a single axis...

East: Let's work on 3.0; whatever is going on in 2.4 won't distract me,
I won't spend time reviewing enhancements, because 3.0 is the goal.

West: Let's keep the energy going on 2.4 enhancements, I won't spend
time on 3.0 usability because it isn't ready or necessary.


Can I put my checkmark in "neither"?

I'm in favor of a 2.6 and/or 3.0 release when it's obvious that the 
benefits to us and our users outweigh the costs of spinning up another 
release branch, and at this point in time I'm not convinced we've 
reached that tipping point.


Until we get there, I would like to continue backporting as much as 
possible from trunk. Those who are following the 2.4.x branches in 
production will get the most benefit; those who are locked to a distro 
snapshot will miss out, sure, but they're missing out anyway. (We can 
probably help *marginally* with that by separating bugfix releases from 
feature releases. There's another in-progress thread with that suggestion.)



So I'd like to know, in light of a perpetual chain of (often build
and/or run-time breaking regression) enhancements, if there is support
for a 2.4.24.x release chain during the 3.0 transition? And support for
potentially 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious
bug fixes?


I'll echo Eric here -- if it's necessary, sure. I'm not convinced it's 
necessary yet. There are other ways to ensure quality releases, and 
there are two or three threads actively discussing them, and I'll be 
actively committing time to pursue some of them.


--Jacob

Re: Automated tests

[Jacob Champion]

On 12/30/2016 02:55 PM, Stefan Fritsch wrote:

Yes, httpd lacks unit tests. One problem is that many APIs depend on very
complex structs like request_rec, conn_rec, server_conf, etc. In order to
write unit tests for such APIs, one would need to write quite a bit of
infrastructure to set these things up. I think it would be worth the effort,
but it's not a small task. As there does not seem to be anybody with enough
spare time to do it, one could possibly ask someone (CII?) for funding.

A possible approach would be to compile the unit tests in the server and
execute them on startup if a special define is given (like the various DUMP_*
defines). Not sure how to get access to all the static helper function for unit
tests, though. Unless one would somehow include the tests in the same .c file.


That's an interesting idea. To riff on that a little bit: I've seen some 
questions on #httpd recently about the shared-library build for 
libhttpd, which IIUC only exists on Windows at the moment. It seems like 
having a libhttpd would simplify building a unit test executable... can 
anyone point me to the history behind the removal of that feature?



If the test suite would be easier to run, maybe more people would submit
tests. Is there a reason why the test suite is in a separate repository? Would
it help if it was moved into the normal httpd repo? Would it make sense to
include it in the release tarballs, possibly including the necessary non-
standard perl modules? And include it in the makefiles in a way that a user can
install a set of standard perl modules (from a distribution or cpan) and then
call "make test" to start it. What is in the test/ dir in the httpd repo right
now seems mostly useless and could probably be removed.


My personal end goals are
- to be able to perform the standard `make && make check` invocation 
without installation (this was discussed with a user in another dev@ thread)
- to have a bugfix/feature *and* its related tests in the same commit or 
backported patchset


So, to that end, I'd like to see the test suite eventually move into the 
httpd repo. I think I can start on my first goal without that, though 
(and I plan to start looking at that soon). That will hopefully give us 
time to discuss any possible fallout of merging the two codebases, while 
giving us some of the benefits in the meantime.



Another idea to make writing tests more attractive could be to somehow include
it in the backporting policy. For example, if there is a test for a new
feature (positive and error handling) or a bug fix, we could require only two
+1s for a backport.


I like this idea too.


Another thing that is missing: A buildbot that builds current trunk (and
possibly 2.x branches) and runs the test suite and alerts the dev list of
regressions. I guess this "just" needs a volunteer to set it up and document
it and the ASF would provide the infrastructure.


+1. This is a prerequisite to having a nice release cadence, IMHO.

--Jacob

Re: A new release process?

[Jacob Champion]

On 12/29/2016 08:16 PM, David Zuelke wrote:

The tl;dr of this approach is that

- any x.y.z release only introduces bugfixes. These releases are done
every four weeks, like clockwork. If a fix doesn't make the cut for a
release, it'll end up in the next one; - x.y.0 releases, on the other
hand, may introduce new features, fixes, and deprecations, but no
breaking changes; - x.0.0 releases are the big ones (think PHP 7.0.0
in late 2015). where backward compatibility may be changed, etc.


My favorite pieces here are
- the introduction of a release cadence
- the separation of bugfix releases from feature releases

Both make life easier -- for us, for users, and for intermediate 
maintainers -- for the reasons you've mentioned.



[...]

There are a bunch of technicalities that would need adjusting to fit
HTTPD, such as release intervals, release management (for PHP, every
x.y.* series has two managers who jointly coordinate releases), etc,
but overall the idea is, IMO, worth considering.


Our current process is also fairly labor-intensive, so moving to a quick 
release cadence without simultaneously fixing that is not likely to end 
up well, IMO. There are other discussions on the list for improving our 
automated QA, which I think is probably step 1.



As a, more or less, "outside observer", I happen to think that the
current method of voting on finals, instead of a practice of rolling
out RCs (that are then left up for testing for at least a week), is
fundamentally broken. The 2.4 changelog in particular is littered
with releases that were never officially published. For users, that's
really confusing.


To a certain extent I think this is something that people get used to 
easily... but for security patches in *particular*, I agree. It's 
disconcerting to hear that CVE 2099-BLAH was fixed in 2.4.Z and then 
find out that 2.4.Z was never released.



For maintainers, it's painful to start over the
process each time, and it sometimes leads to months and months
without a release that contains certain fixes.


The pain of discarding and restarting your manual tests because someone 
else found a regression on another platform two hours into the release 
vote comes to mind, yes.


For the record, though, I think having strong automated QA processes 
will help both of these issues more than the release cadence will. It's 
just that the cadence reinforces the QA and the QA reinforces the 
cadence; they go hand-in-hand in a very nice positive feedback loop.



Then a backport goes
wrong (still using SVN, in my opinion, does not help there, but
that's a whole different discussion :)),


I've started some discussions on how we might introduce feature- and 
fix-branches, and hopefully better backport workflows, into our current 
use of SVN. (I'm a git user myself, and the current backport process is 
more error-prone than I'm used to as well. But I have no desire to start 
a holy war, and I'm confident we can find an SVN workflow that works well.)



and a regression is in the
latest release until someone eventually picks up a fix.

Much of this, and many of the "what do we backport from trunk" and
"I'd like to squeeze in a change I've had sitting around locally,
please wait with the new release, because who knows when the next one
after that will be" are, from what I can tell, a significant source
of discord on this mailing list. All these unnecessary distractions
that deteriorate personal relationships, while at the same time
slowing down the pace of the project (several people have already
pointed out Nginx's rate of innovation in comparison) and raising the
threshold for contributions, can be fixed. PHP is the perfect
example, and I think HTTPD would be wise to at least consider
following this example.

Happy New Year!


Thanks for your input!

--Jacob

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

Bill, your Email client is messed-up again, as related to
how it handles copy/pasted text in replies.

> On Jan 3, 2017, at 9:07 AM, William A Rowe Jr  wrote:
> 
> On Jan 3, 2017 02:19, "Graham Leggett"  wrote:
> 
> > Can you clarify the problem you’re trying to solve?
> > 
> > v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a 
> > very large architecture change (for example, the > addition of filters in 
> > v1.x to v2.x), we move to 3.0.
> >
> > Is there a very large architecture change planned by anybody?
> >
> > In my experience, things that felt initially like big changes have actually 
> > turned out to be rather modest changes that are > still possible to 
> > backport to v2.4 without an issue. For this reason I haven’t seen a reason 
> > to push very hard for v2.6, > > never mind v3.0.
> 
> I do, the very specific problem is that trunk/, and therefore all 
> more-than-modest (or just neglected) contributions are now four years stale 
> and abandoned.
> 
> A certain way to push off contributors is to ignore their patch submissions. 
> The second method is to commit them to a dead fork.
> 
> If trunk/ is a dead fork, it may be time for httpd to admit this, trash it 
> and re-fork trunk from 2.4.x branch.

Who said this? Who even implied it? And how do you align what
you just wrote with your complaints when people try to "encourage"
backports of stuff in trunk to 2.4.x?

There are some things in trunk that admittedly can't be backported,
and those, if worthwhile, should be reason and rationale for
getting httpd-next out.

The issue, if I may be so bold, is that some people likely
don't want to spend the time and trouble backporting because
other people use that as an opportunity to shout out "No more
enhancements on 2.4! You are wasting your time!" and who, after
all, wants to deal with the potential drama?

Personally, I would <3 to see the additional async stuff
in people's hands asap.

> 
> Beyond this, see the recent appeal for major.minor breaking change wish list 
> on trunk/STATUS, that is a different thread for you to chime in on.
> 
> Back to topic, who is interested in a stable release chain, since 2.4.x has 
> not been that?

IMO, 2.4.x has been that. I see no real justification
to suggest otherwise.

Re: svn commit: r1775789 - /httpd/httpd/branches/2.2.x/STATUS

[William A Rowe Jr]

On Tue, Jan 3, 2017 at 11:04 AM, William A Rowe Jr  wrote:
> On Tue, Jan 3, 2017 at 9:55 AM, Eric Covener  wrote:
>> I am not completely following how the branch or patch were assembled,
>> but I am seeing a failure that is missing content from the initial
>> trunk work (1426877)
>> that was also in the initial 2.4.x backport (1772678).
>>
>> It is causing frequent crashes on EOF of a keepalive conn for me
>>
>> The missing bit that sticks out/causes the crash is server/protocol.c
>> ap_read_request():
>>
>> 1276 default:
>> 1277 apr_brigade_destroy(tmp_bb);
>> 1278 r = NULL;
>>  ^ missing
>> 1279 return r;
>> 1280 }
>> 1281 }
>> 1282
>>
>> Bill do you recall if there was perhaps a hand-resolved merge conflict
>> in this area?
>
> That makes perfect sense due to the s/goto traceout/return r/ conflicts,
> none of the patch applied in that section, and I simply missed this line.
> The traceout change wasn't merged since 2.2 has no support for that
> loglevel.
>
> Feel free to patch on the merge branch, or I will fix this myself this
> afternoon.

Looking more closely at this code, the four essential errors all return
NULL, and default: should have returned NULL, which leaves me
wondering why HTTP_REQUEST_TIMEOUT returns the request_rec
when no other error cases do so?

Re: svn commit: r1775789 - /httpd/httpd/branches/2.2.x/STATUS

[William A Rowe Jr]

On Tue, Jan 3, 2017 at 9:55 AM, Eric Covener  wrote:
> I am not completely following how the branch or patch were assembled,
> but I am seeing a failure that is missing content from the initial
> trunk work (1426877)
> that was also in the initial 2.4.x backport (1772678).
>
> It is causing frequent crashes on EOF of a keepalive conn for me
>
> The missing bit that sticks out/causes the crash is server/protocol.c
> ap_read_request():
>
> 1276 default:
> 1277 apr_brigade_destroy(tmp_bb);
> 1278 r = NULL;
>  ^ missing
> 1279 return r;
> 1280 }
> 1281 }
> 1282
>
> Bill do you recall if there was perhaps a hand-resolved merge conflict
> in this area?

That makes perfect sense due to the s/goto traceout/return r/ conflicts,
none of the patch applied in that section, and I simply missed this line.
The traceout change wasn't merged since 2.2 has no support for that
loglevel.

Feel free to patch on the merge branch, or I will fix this myself this
afternoon.

Re: svn commit: r1775789 - /httpd/httpd/branches/2.2.x/STATUS

[Eric Covener]

I am not completely following how the branch or patch were assembled,
but I am seeing a failure that is missing content from the initial
trunk work (1426877)
that was also in the initial 2.4.x backport (1772678).

It is causing frequent crashes on EOF of a keepalive conn for me

The missing bit that sticks out/causes the crash is server/protocol.c
ap_read_request():

1276 default:
1277 apr_brigade_destroy(tmp_bb);
1278 r = NULL;
 ^ missing
1279 return r;
1280 }
1281 }
1282

Bill do you recall if there was perhaps a hand-resolved merge conflict
in this area?

On Fri, Dec 23, 2016 at 12:24 AM,   wrote:
> Author: wrowe
> Date: Fri Dec 23 05:24:54 2016
> New Revision: 1775789
>
> URL: http://svn.apache.org/viewvc?rev=1775789=rev
> Log:
> This was my entire intended commit. But as an alternate strategy, you can
> svn up to r1775787. Not that I intended it, and absolutely not the way we
> should apply it (revert layer by layer 6 commits replicated on the merge
> branch, then apply merge branch in one commit, IMO.)
>
> Sorry folks ;-/
>
> Modified:
> httpd/httpd/branches/2.2.x/STATUS
>
> Modified: httpd/httpd/branches/2.2.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=1775789=1775788=1775789=diff
> ==
> --- httpd/httpd/branches/2.2.x/STATUS (original)
> +++ httpd/httpd/branches/2.2.x/STATUS Fri Dec 23 05:24:54 2016
> @@ -99,6 +99,32 @@ CURRENT RELEASE NOTES:
>
>  RELEASE SHOWSTOPPERS:
>
> +  *) Rather than odds-and-ends applied out of order, proposing we revert
> + r1757240, r1757256, r1757295, r1758671, r1758672, r1775232, all of
> + which is now recorded in the 2.2.x-merge-http-strict branch, and
> + bring that branch back into 2.2.x for 2.4.32 release.
> + Merges;
> +   -c-1775232 .
> +   -c-1757672 .
> +   -c-1757671 .
> +   -c-1757295 .
> +   -c-1757256 .
> +   -c-1757240 .
> + [here we are back at 2.2.32-dev bump]
> +   -r1775685:1775780 
> https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x-merge-http-strict/
> + Roll-up patch of the above (not recommended for casual reading, these
> + would be committed individually as noted above... but for only for 
> sanity
> + testing the end result. Due to intervening CHANGES/ap_mmn changes, there
> + is small delta after reverting the above...)
> +   
> https://raw.githubusercontent.com/wrowe/patches/master/httpd-2.2-HEAD-http-protocol-strict.patch
> +   This patch above does *NOT* apply to the 2.2.31 release, c.f. the 
> delta
> +   of the 2.2.x-merge-http-strict branch for that information. This is 
> for
> +   folks who are testing rollbacks plus 2.4.x activity against 2.2.x 
> HEAD!
> +   Sorry to start from scratch, but yann's correct observation was 
> correct,
> +   that nothing will apply out-of-order, and everything on 2.2 branch had
> +   already become disordered.
> + +1: wrowe
> +
>
>  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
>[ start all new proposals below, under PATCHES PROPOSED. ]
> @@ -152,44 +178,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>   http://home.apache.org/~ylavic/patches/httpd-2.2.x-r1753592.patch
>+1: ylavic
>
> -  *) Enforce LimitRequestFieldSize after multiple headers with the same
> - name have been merged, Ensure LimitRequestFieldSize is always logged.
> - Downgrade some more log messages indicating client errors from level 
> error
> - to info. Add log messages for various reasons to return 
> HTTP_BAD_REQUEST.
> - Correctly return a 400 (Bad request) in case of a HTTP/0.9 request like
> - "GET @example.org/foo".
> - Add some trace logging to core (using AP_DEBUG_THE_REQUEST macro, 
> because
> - the TRACE5 facilities aren't in 2.2.x branch).
> - Improve error message (PR 54384).
> - Submitted by: sf, rpluem, jailletc36
> - [Note: everything in this patch is modifying logging and brings in the
> - LimitRequestFieldSize logic used for the lifespan of 2.4.x]
> - Trunk version of patch
> - http://svn.apache.org/r951900 (server/protocol.c alone)
> - http://svn.apache.org/r1178566
> - http://svn.apache.org/r1185385
> - http://svn.apache.org/r1188745
> - http://svn.apache.org/r1352911
> - http://svn.apache.org/r1433613
> - Backport: (Adjustments dodging 2.4'isms such as APLOGNO's)
> - 
> https://raw.githubusercontent.com/wrowe/patches/master/backport-2.2.x-r951900-r1178566-r1185385-r1188745-r1352911-r1433613.patch
> - +1: wrowe, covener
> - ylavic: the patch does not apply cleanly? (I tried both w/ and w/o
> - backport-2.2.x-r892678.patch first, conflicts in protocol.c)
> -
> -  *) core: ErrorDocument now works for requests without a Host header.
> - Support custom 

Re: [proposed] 2.4 Maintenance SIG

[Steffen]

>Nobody built on Windows prior to the release so 
>we had a re-roll. 

Please contact me before a release, so I can test. 

Steffen AL



--- Begin Message  
Group: gmane.comp.apache.devel 
MsgID: 

Re: [proposed] 2.4 Maintenance SIG

[Graham Leggett]

On 03 Jan 2017, at 4:07 PM, William A Rowe Jr  wrote:

> Can you clarify the problem you’re trying to solve?
> 
> v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a 
> very large architecture change (for example, the addition of filters in v1.x 
> to v2.x), we move to 3.0.
> 
> Is there a very large architecture change planned by anybody?
> 
> In my experience, things that felt initially like big changes have actually 
> turned out to be rather modest changes that are still possible to backport to 
> v2.4 without an issue. For this reason I haven’t seen a reason to push very 
> hard for v2.6, never mind v3.0.
> 
> I do, the very specific problem is that trunk/, and therefore all 
> more-than-modest (or just neglected) contributions are now four years stale 
> and abandoned.
> 
> A certain way to push off contributors is to ignore their patch submissions. 
> The second method is to commit them to a dead fork.

I’m not following this logic.

The rules are patches are committed to trunk first, and therefore trunk is 
never dead by definition. People either backport the change to v2.4, or they 
wait for 2.6. The backport to v2.4 happens immediately, waiting for v2.6 either 
means “I’m happy to wait for v2.6” or it means “I’m not happy to wait, so let’s 
release v2.6”.

This is how it has always been, and I see no problem with this pattern.

> If trunk/ is a dead fork, it may be time for httpd to admit this, trash it 
> and re-fork trunk from 2.4.x branch.

We would obviously never do this, at to do so would treat our contributors with 
contempt.

> Beyond this, see the recent appeal for major.minor breaking change wish list 
> on trunk/STATUS, that is a different thread for you to chime in on.
> 
> Back to topic, who is interested in a stable release chain, since 2.4.x has 
> not been that?

I still don’t understand the problem you’re trying to solve, v2.4.x has 
certainly been a very effective stable release chain. Or more accurately, I do 
not see any problem that cannot be solved by our current process, which is a 
choice between the following:

- backport the stuff to v2.4; otherwise
- release v2.6 and continue.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

On Jan 3, 2017 07:11, "Jim Jagielski"  wrote:

Back in the "old days" we used to provide complimentary builds
for some OSs... I'm not saying we go back and do that necessarily,
but maybe also providing easily consumable other formats when we
do a release, as a "service" to the community might make a lot
of sense.


It could be really helpful. Or we can follow svn's lead and hand it
entirely off to the broader community, which proved really effective on
Windows, given the number of distros to now choose between. I haven't seen
similar for RHEL users, for example.

That said, only one major Linux distro (April Ubuntu LTS) is at OpenSSL
1.0.2, which is a necessary part of http/2's special sauce.

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Jan 3, 2017 02:19, "Graham Leggett"  wrote:


Can you clarify the problem you’re trying to solve?

v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a
very large architecture change (for example, the addition of filters in
v1.x to v2.x), we move to 3.0.

Is there a very large architecture change planned by anybody?

In my experience, things that felt initially like big changes have actually
turned out to be rather modest changes that are still possible to backport
to v2.4 without an issue. For this reason I haven’t seen a reason to push
very hard for v2.6, never mind v3.0.


I do, the very specific problem is that trunk/, and therefore all
more-than-modest (or just neglected) contributions are now four years stale
and abandoned.

A certain way to push off contributors is to ignore their patch
submissions. The second method is to commit them to a dead fork.

If trunk/ is a dead fork, it may be time for httpd to admit this, trash it
and re-fork trunk from 2.4.x branch.

Beyond this, see the recent appeal for major.minor breaking change wish
list on trunk/STATUS, that is a different thread for you to chime in on.

Back to topic, who is interested in a stable release chain, since 2.4.x has
not been that?

Re: [proposed] 2.4 Maintenance SIG

[Eric Covener]

On Mon, Jan 2, 2017 at 7:11 PM, William A Rowe Jr  wrote:
> So I'd like to know, in light of a perpetual chain of (often build and/or
> run-time breaking regression) enhancements, if there is support for a
> 2.4.24.x release chain during the 3.0 transition? And support for
> potentially 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious bug
> fixes?

Not personally in favor of it, but would help maintain it if that's
what the community wants.

I don't recall much breakage in 2.4 over the past 6 months, much less
breakage that would have impeded anyones work for a significant amount
of time.  Nobody built on Windows prior to the release so we had a
re-roll.  I don't think the corrective action here is a new service
stream.

-- 
Eric Covener
cove...@gmail.com

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jim Jagielski]

Back in the "old days" we used to provide complimentary builds
for some OSs... I'm not saying we go back and do that necessarily,
but maybe also providing easily consumable other formats when we
do a release, as a "service" to the community might make a lot
of sense.

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

> On Jan 2, 2017, at 7:11 PM, William A Rowe Jr  wrote:
> 
> So far, discussions are polarized on a single axis...
> 
> East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I 
> won't spend time reviewing enhancements, because 3.0 is the goal.
> 
> West: Let's keep the energy going on 2.4 enhancements, I won't spend time on 
> 3.0 usability because it isn't ready or necessary.
> 

I have not really seen things as polarized as you make out, at
least as represented by the "West" strawman.

Re: [proposed] 2.4 Maintenance SIG

[Graham Leggett]

On 03 Jan 2017, at 2:11 AM, William A Rowe Jr  wrote:

> So far, discussions are polarized on a single axis...
> 
> East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I 
> won't spend time reviewing enhancements, because 3.0 is the goal.
> 
> West: Let's keep the energy going on 2.4 enhancements, I won't spend time on 
> 3.0 usability because it isn't ready or necessary.
> 
> There is a disconnect, because 'East' folks can't actually put up with the 
> breakage introduced by enhancements they can't review on 2.4, but all feel 
> responsible to keeping 2.4 usable to EOL.
> 
> So I'd like to know, in light of a perpetual chain of (often build and/or 
> run-time breaking regression) enhancements, if there is support for a 
> 2.4.24.x release chain during the 3.0 transition? And support for potentially 
> 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious bug fixes?
> 
> It's clear this project doesn't agree, so the question twists to how we agree 
> to disagree.

Can you clarify the problem you’re trying to solve?

v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a very 
large architecture change (for example, the addition of filters in v1.x to 
v2.x), we move to 3.0.

Is there a very large architecture change planned by anybody?

In my experience, things that felt initially like big changes have actually 
turned out to be rather modest changes that are still possible to backport to 
v2.4 without an issue. For this reason I haven’t seen a reason to push very 
hard for v2.6, never mind v3.0.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature