You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@serf.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2020/03/31 16:53:20 UTC

1.3.x sweep and 1.4.x timeline?

Hi all!

I hope that everyone is doing as well as they can in these times.

I'd like to do a sweep of STATUS and do a final 1.3.x release that captures
the relevant build system and test fixes.  I'll try to test out the Visual
Studio fixes that are pending for 1.3.x; I have VS 2019 here, so I may try
to see if there are additional fixes required for VS 2019 as well.

I also see the changes for OpenSSL/LibreSSL in 1.3.x STATUS - it looks like
the OpenSSL 1.1.x patches that were already merged in 1.3.9 obsolete that
branch; but, I'm open to whether we want to do something with LibreSSL as
well.  Thoughts?

What do folks think about cutting a 1.4.x release as well?  I see that
there are a number of good bits there that have yet to see a formal
release, so I'm open to also cutting a 1.4.0 release too over the next few
weeks.

Once I have the tree ready for 1.3.x and 1.4.x, I'll ask for votes.  I'm
optimistic that we can get a quorum of 3 people to cut a release.  =)

Cheers.  -- justin

Re: 1.3.x sweep and 1.4.x timeline?

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Apr 1, 2020 at 1:10 PM Ivan Zhakov <iv...@visualsvn.com> wrote:

> On Tue, 31 Mar 2020 at 23:13, Justin Erenkrantz <ju...@erenkrantz.com>
> wrote:
> >
> > On Tue, Mar 31, 2020 at 2:33 PM Branko Čibej <br...@apache.org> wrote:
> >
> > > Thanks, Justin. I don't know if we need another 1.3.x release, given
> > > that 1.4 will be API compatible and has more robust OpenSSL 1.1.x and
> > > LibreSSL support.
> > >
> >
> > My preference would be to just do a small 1.3.x release out with critical
> > build/test fixes; but, if I'm alone and folks want to jump to a 1.4.0 and
> > the downstream packagers are fine with upgrading to that, I can be
> > convinced to just skip and go to 1.4.0; but, there's probably a longer
> > turnaround for getting 1.4.0 out the door though.
> >
> +1.


Given the upstream OpenSSL reversion, I think I'm now leaning towards just
focusing on a 1.4.0 release.

I went through the motions of trying out the CMake process on Windows - I
got lost a bit in the dependency chain, but it does seem promising.
(Expat, APR, APR-util are all on CMake now; OpenSSL isn't quite yet,
AFAICT.)

On a related note, I'm intrigued in expressing the dependency chain via
Buildstream - which is going to be moving over to Apache (via Petri):

https://mail.gnome.org/archives/buildstream-list/2020-April/msg00010.html

At a high-level, the new CMake build system would stay the same, but
there'd be a set of files to help bootstrap the build process for beginners
and downstream package maintainers.  I could see that benefiting APR,
APR-util, httpd, and Subversion too...so, I think I'm going to take a pass
at trying to see what that'd look like.  That would make me a bit more
comfortable about the switch to CMake for 1.4.0.  Here's an example of a
Buildstream repos for Apache Arrow (which is similarly complex):

https://gitlab.com/BenjaminSchubert/apache-arrow-build-buildstream-demo-2019


Cheers.  -- justin

Re: 1.3.x sweep and 1.4.x timeline?

Posted by Ivan Zhakov <iv...@visualsvn.com.INVALID>.
On Tue, 31 Mar 2020 at 23:13, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>
> On Tue, Mar 31, 2020 at 2:33 PM Branko Čibej <br...@apache.org> wrote:
>
> > Thanks, Justin. I don't know if we need another 1.3.x release, given
> > that 1.4 will be API compatible and has more robust OpenSSL 1.1.x and
> > LibreSSL support.
> >
>
> My preference would be to just do a small 1.3.x release out with critical
> build/test fixes; but, if I'm alone and folks want to jump to a 1.4.0 and
> the downstream packagers are fine with upgrading to that, I can be
> convinced to just skip and go to 1.4.0; but, there's probably a longer
> turnaround for getting 1.4.0 out the door though.
>
+1.


-- 
Ivan Zhakov

Re: 1.3.x sweep and 1.4.x timeline?

Posted by James McCoy <ja...@debian.org>.
On Tue, Mar 31, 2020 at 04:13:40PM -0400, Justin Erenkrantz wrote:
> On Tue, Mar 31, 2020 at 2:33 PM Branko Čibej <br...@apache.org> wrote:
> 
> > Thanks, Justin. I don't know if we need another 1.3.x release, given
> > that 1.4 will be API compatible and has more robust OpenSSL 1.1.x and
> > LibreSSL support.
> >
> 
> My preference would be to just do a small 1.3.x release out with critical
> build/test fixes; but, if I'm alone and folks want to jump to a 1.4.0 and
> the downstream packagers are fine with upgrading to that, I can be
> convinced to just skip and go to 1.4.0;

FWIW, there's not much difference to me whether the next release is
1.3.x or 1.4.x.  I'll get a fixed test suite either way. :)

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: 1.3.x sweep and 1.4.x timeline?

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Mar 31, 2020 at 2:33 PM Branko Čibej <br...@apache.org> wrote:

> Thanks, Justin. I don't know if we need another 1.3.x release, given
> that 1.4 will be API compatible and has more robust OpenSSL 1.1.x and
> LibreSSL support.
>

My preference would be to just do a small 1.3.x release out with critical
build/test fixes; but, if I'm alone and folks want to jump to a 1.4.0 and
the downstream packagers are fine with upgrading to that, I can be
convinced to just skip and go to 1.4.0; but, there's probably a longer
turnaround for getting 1.4.0 out the door though.


> For 1.4, we have (had? not quite up to date here...) the proposed Python
> 3 fixes which I'd treat as mandatory. The CMake build doesn't support
> BROTLI and GSSAPI yet, but that's not a blocker for the release IMO. A
> bulk merge to the 1.4.x branch would make sense, too; I don't think we
> have to go through STATUS for the minor improvements currently on trunk.
>

Given the activity on the project, I'm kind of the mindset that we shift to
having all of our branches be CTR and just require 3 +1s on a release
rather than doing every patchset on a one-off basis in STATUS or whatnot.

What do folks think of that shift?

Cheers.  -- justin

Re: 1.3.x sweep and 1.4.x timeline?

Posted by Branko Čibej <br...@apache.org>.
On 31.03.2020 18:53, Justin Erenkrantz wrote:
> Hi all!
>
> I hope that everyone is doing as well as they can in these times.
>
> I'd like to do a sweep of STATUS and do a final 1.3.x release that captures
> the relevant build system and test fixes.  I'll try to test out the Visual
> Studio fixes that are pending for 1.3.x; I have VS 2019 here, so I may try
> to see if there are additional fixes required for VS 2019 as well.
>
> I also see the changes for OpenSSL/LibreSSL in 1.3.x STATUS - it looks like
> the OpenSSL 1.1.x patches that were already merged in 1.3.9 obsolete that
> branch; but, I'm open to whether we want to do something with LibreSSL as
> well.  Thoughts?
>
> What do folks think about cutting a 1.4.x release as well?  I see that
> there are a number of good bits there that have yet to see a formal
> release, so I'm open to also cutting a 1.4.0 release too over the next few
> weeks.
>
> Once I have the tree ready for 1.3.x and 1.4.x, I'll ask for votes.  I'm
> optimistic that we can get a quorum of 3 people to cut a release.  =)


Thanks, Justin. I don't know if we need another 1.3.x release, given
that 1.4 will be API compatible and has more robust OpenSSL 1.1.x and
LibreSSL support.

For 1.4, we have (had? not quite up to date here...) the proposed Python
3 fixes which I'd treat as mandatory. The CMake build doesn't support
BROTLI and GSSAPI yet, but that's not a blocker for the release IMO. A
bulk merge to the 1.4.x branch would make sense, too; I don't think we
have to go through STATUS for the minor improvements currently on trunk.

-- Brane