Re: officially retire 1.9?
Daniel Shahaf wrote: What's 1.9's new end-of-life date, then? Until what (past or future) date do we _commit_ to backporting critical fixes? The release date of the next LTS release. According to the currently planned release cycles, that will be v1.14 in April 2020. (It might be affected by the outcome of the discussion about stabilizing svn, in which Mark suggested we might want to re-think the release strategy.) - Julian
Re: officially retire 1.9?
Julian Foad wrote on Fri, 16 Aug 2019 09:47 +00:00: > Stefan Sperling wrote: > > [...] > But the amount of work involved in everyone else running tests and > signing > > releases must also be considered. We barely made the required signature > > count > > for our last 3 releases. Focussing our volunteer resources on releases that > > are actually used by Debian and Red Hat (as reference platforms that usually > > ship our "oldest" releases) seems fair. > > > >> So I vote for softly reducing the support effort while leaving it > >> documented > >> as "supported". > > > > That's fine with me. It would more or less amount to the same thing :) > > We have had "security and data corruption fixes only" backport guidelines > > in the past. I'd suggest we could apply this to 1.9. > > Sounds good to me. What's 1.9's new end-of-life date, then? Until what (past or future) date do we _commit_ to backporting critical fixes?
Re: officially retire 1.9?
Stefan Sperling wrote: [...] > But the amount of work involved in everyone else running tests and signing releases must also be considered. We barely made the required signature count for our last 3 releases. Focussing our volunteer resources on releases that are actually used by Debian and Red Hat (as reference platforms that usually ship our "oldest" releases) seems fair. So I vote for softly reducing the support effort while leaving it documented as "supported". That's fine with me. It would more or less amount to the same thing :) We have had "security and data corruption fixes only" backport guidelines in the past. I'd suggest we could apply this to 1.9. Sounds good to me. Thanks. - Julian
Re: officially retire 1.9?
On Mon, Aug 12, 2019 at 03:40:50PM +0100, Julian Foad wrote: > Branko Čibej wrote: > > On 05.08.2019 20:27, Stefan Sperling wrote: > > > Subversion 1.9.0 is 4 years old today (release on August 5 2015). > > > http://subversion.apache.org/roadmap.html#release-planning says that > > > each LTS release is supported for 4 years. > > > > > > Julian said on IRC that perhaps we decided to support 2 LTS releases > > > for either 4 years or until another LTS release appears. > > > Which means 1.9 would still be supported until 1.14 is released. > > We documented "If a release takes longer than planned, we will extend the > support periods of the previous releases accordingly." [1] I intended this > to mean we would continue to apply the spirit of our historical support for > "the current and the previous" releases for the newly designated "LTS" > releases. > > I acknowledge that's not totally clear, and all our decisions can be > reviewed. Thanks for clarifying. Indeed, I missed this. > Let's take a moment to remind other readers that "unsupported" means we > don't expect or intend to make another release; it does not mean there is > absolutely no possibility of a further release if there should be sufficient > justification for the effort required. Right. > Conversely, we can "softly" reduce support for it: we are not obliged to > backport any particular fixes or make any particular number of releases. > > I will say that in recently releasing 1.12.2, 1.10.6, and 1.9.12, the amount > of work I had to do for three release lines compared to two was much less > than proportional. But the amount of work involved in everyone else running tests and signing releases must also be considered. We barely made the required signature count for our last 3 releases. Focussing our volunteer resources on releases that are actually used by Debian and Red Hat (as reference platforms that usually ship our "oldest" releases) seems fair. > So I vote for softly reducing the support effort while leaving it documented > as "supported". That's fine with me. It would more or less amount to the same thing :) We have had "security and data corruption fixes only" backport guidelines in the past. I'd suggest we could apply this to 1.9.
Re: svn commit: r1850651 - /subversion/trunk/subversion/mod_dav_svn/repos.c
On Thu, Aug 15, 2019 at 09:36:48PM +0300, Sergey Raevskiy wrote:
> Hi!
>
> I've attached a patch with fix. Log message:
> [[[
> * subversion/mod_dav_svn/repos.c
> (get_resource): Following up on r1850651: Set cleanup handler for
>FS warning logging regardless of presence of R->USER.
>
> Patch by: sergey.raevskiy{_AT_}visualsvn.com
> ]]]
Thank you Sergey!
I can confirm FSFS/serf tests still pass with this patch on an OpenBSD
System. Which means the original use-after-free issue remains fixed.
Committed in r1865266.
Regards,
Stefan
