You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2020/03/10 11:23:49 UTC
branching 1.14.x
As previously discussed, I would like to create the 1.14.x branch
soon in order to begin the release process for 1.14.0.
There are two changes being worked on which look important and
which, I believe, could only be introduced in a dot zero release
since they violate our patch release compatibility guarantees:
1. The 'decouple-shelving-cli' branch
2. The editor path fixes which don't yet work on Windows.
Did I miss anything?
I'm wondering if we should wait with creating the 1.14.x branch
until the above changes have settled.
Alternatively, we could create the branch now and allow these
changes to be merged before 1.14.0; beyond that point these
changes could miss the boat and might have to wait until 1.15.
Re: branching 1.14.x
Posted by Nathan Hartman <ha...@gmail.com>.
On Sat, Mar 14, 2020 at 10:30 AM Julian Foad <ju...@apache.org> wrote:
> Stefan Sperling wrote:
> > We also need people to test and sign the releases across OS platforms.
> > At a minimum there will be 1.14.0-rc1 and 1.14.0 releases to test and
> sign.
>
> I expect to be able to test and sign on Linux.
Looks like I'm late to the party. A few days ago, I read the article that
(I think) James sent about the Windows command escaping problem and suffice
it to say it gave me a headache. Thanks, James, for working on it!!
I will help with testing and signing (Linux, macOS).
As mentioned by others previously I'm helping with the release notes as
well, and I'll improve the text about the experimental features per
Daniel's suggestions (and whatever else might change) soon.
Just for the record, my involvement has suffered lately because of a string
of emergencies (the latest being the mess with this corona business). It is
*not* because of lack of interest in the project.
Everyone stay healthy,
Nathan
Re: branching 1.14.x
Posted by Julian Foad <ju...@apache.org>.
Stefan Sperling wrote:
> We also need people to test and sign the releases across OS platforms.
> At a minimum there will be 1.14.0-rc1 and 1.14.0 releases to test and sign.
I expect to be able to test and sign on Linux.
- Julian
Re: branching 1.14.x
Posted by Mark Phippard <ma...@gmail.com>.
> On Mar 14, 2020, at 10:32 AM, James McCoy <ja...@jamessan.com> wrote:
>
> On Sat, Mar 14, 2020 at 03:26:48PM +0100, Stefan Sperling wrote:
>>> On Sat, Mar 14, 2020 at 10:12:41AM -0400, Mark Phippard wrote:
>>> My only advice would be to reach a point where we accept no one is going to
>>> step up and fix this on Windows and then decide accordingly. If we can fix it
>>> for Linux without making Windows any worse, then I would think we should do
>>> that. I do not see why we cannot leave the tests failing on Windows. Again,
>>> as long as we have not made Windows any worse, if some future APR update were
>>> to make the tests pass that sounds like a good thing.
>>>
>>> As long as we know why the tests fail, that seems acceptable to me. If we
>>> cannot fix Linux without making Windows worse than it is with 1.13 then that
>>> is different and more complicated for sure.
>>
>> I cannot really judge the impact on Windows. Apparently, the change
>> breaks things on Windows because APR's code doesn't work properly there.
>>
>> Let's wait a bit and see if developers involved will speak up.
>
> I'm working on it now. I should be able to have something that avoids
> regressions on Windows this weekend.
Thank you!
Mark
Re: branching 1.14.x
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 14, 2020 at 10:32:04AM -0400, James McCoy wrote:
> I'm working on it now. I should be able to have something that avoids
> regressions on Windows this weekend.
>
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Great news. Thank you James!
Re: branching 1.14.x
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 16, 2020 at 12:26:18AM -0400, James McCoy wrote:
> On Sat, Mar 14, 2020 at 10:32:04AM -0400, James McCoy wrote:
> > I'm working on it now. I should be able to have something that avoids
> > regressions on Windows this weekend.
>
> Done in r1875230.
Thanks James. Looks good to me.
Barring newly discovered problems it looks like there are no blockers left?
If so I will start the release process some time this week.
Do you think it would be worthwhile to try pushing your Windows-specific
quoting code to APR, such that apr_escape_shell() will handle this in the
future? Or is there some reason against this?
Thanks,
Stefan
Re: branching 1.14.x
Posted by James McCoy <ja...@jamessan.com>.
On Sat, Mar 14, 2020 at 10:32:04AM -0400, James McCoy wrote:
> On Sat, Mar 14, 2020 at 03:26:48PM +0100, Stefan Sperling wrote:
> > On Sat, Mar 14, 2020 at 10:12:41AM -0400, Mark Phippard wrote:
> > > My only advice would be to reach a point where we accept no one is going to
> > > step up and fix this on Windows and then decide accordingly. If we can fix it
> > > for Linux without making Windows any worse, then I would think we should do
> > > that. I do not see why we cannot leave the tests failing on Windows. Again,
> > > as long as we have not made Windows any worse, if some future APR update were
> > > to make the tests pass that sounds like a good thing.
> > >
> > > As long as we know why the tests fail, that seems acceptable to me. If we
> > > cannot fix Linux without making Windows worse than it is with 1.13 then that
> > > is different and more complicated for sure.
> >
> > I cannot really judge the impact on Windows. Apparently, the change
> > breaks things on Windows because APR's code doesn't work properly there.
> >
> > Let's wait a bit and see if developers involved will speak up.
>
> I'm working on it now. I should be able to have something that avoids
> regressions on Windows this weekend.
Done in r1875230.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: branching 1.14.x
Posted by James McCoy <ja...@jamessan.com>.
On Sat, Mar 14, 2020 at 03:26:48PM +0100, Stefan Sperling wrote:
> On Sat, Mar 14, 2020 at 10:12:41AM -0400, Mark Phippard wrote:
> > My only advice would be to reach a point where we accept no one is going to
> > step up and fix this on Windows and then decide accordingly. If we can fix it
> > for Linux without making Windows any worse, then I would think we should do
> > that. I do not see why we cannot leave the tests failing on Windows. Again,
> > as long as we have not made Windows any worse, if some future APR update were
> > to make the tests pass that sounds like a good thing.
> >
> > As long as we know why the tests fail, that seems acceptable to me. If we
> > cannot fix Linux without making Windows worse than it is with 1.13 then that
> > is different and more complicated for sure.
>
> I cannot really judge the impact on Windows. Apparently, the change
> breaks things on Windows because APR's code doesn't work properly there.
>
> Let's wait a bit and see if developers involved will speak up.
I'm working on it now. I should be able to have something that avoids
regressions on Windows this weekend.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: branching 1.14.x
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Sat, 14 Mar 2020 16:59 +0100:
> On Sat, Mar 14, 2020 at 03:47:44PM +0000, Daniel Shahaf wrote:
> > What is it that I'm supposed to share my assessment of? My involvement
> > in shelving consisted of little more than conducting two commit
> > reviews.
>
> Whether you're OK with that code you've reviewed to be shipped as it is.
> It sounds like you have no concerns and we're good :)
I have reviewed subversion/svn/svn.c:2071-2081 and am happy for those
eleven lines to be shipped as is.
I have also reviewed the test suite support for those lines, and have
raised a concern that has not yet been addressed:
https://mail-archives.apache.org/mod_mbox/subversion-dev/202002.mbox/%3C77bc96f0-6d5a-4f77-8d69-029e77fc4380%40www.fastmail.com%3E
(tl;dr: the shelf2/shelf3 tests don't run by default, but should, but
the implementation is not as simple as setting an environment variable
globally.)
As to the assessing the releasability of the remaining 10k LOC of the
shelving feature, I have not reviewed them so I defer to Julian.
Cheers,
Daniel
(There's also the release notes for shelving, which are being worked on
and in any case don't block branching or rolling.)
Re: branching 1.14.x
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 14, 2020 at 03:47:44PM +0000, Daniel Shahaf wrote:
> What is it that I'm supposed to share my assessment of? My involvement
> in shelving consisted of little more than conducting two commit
> reviews.
Whether you're OK with that code you've reviewed to be shipped as it is.
It sounds like you have no concerns and we're good :)
Re: branching 1.14.x
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Sat, 14 Mar 2020 15:26 +0100:
> On Sat, Mar 14, 2020 at 10:12:41AM -0400, Mark Phippard wrote:
> > I do not fully understand where we are at on shelving. I believe ideas were
> > proposed to make it a compile time feature that would be off by default or
> > something. I am fine with that. You raised it as being a blocker still so I
> > am going off what you wrote. If it was merged and not a blocker then were you
> > just looking for Julian or Daniel or someone else to officially say it is no
> > longer a blocker?
>
> The 'decouple-shelving-cli' branch was not merged to trunk yet when
> I started this thread. So progress has been made.
>
> And yes, knowing Daniel's and Julian's assessment of the current state
> of things would be good.
What is it that I'm supposed to share my assessment of? My involvement
in shelving consisted of little more than conducting two commit
reviews.
Cheers,
Daniel
Re: branching 1.14.x
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 14, 2020 at 10:12:41AM -0400, Mark Phippard wrote:
> I do not fully understand where we are at on shelving. I believe ideas were
> proposed to make it a compile time feature that would be off by default or
> something. I am fine with that. You raised it as being a blocker still so I
> am going off what you wrote. If it was merged and not a blocker then were you
> just looking for Julian or Daniel or someone else to officially say it is no
> longer a blocker?
The 'decouple-shelving-cli' branch was not merged to trunk yet when
I started this thread. So progress has been made.
And yes, knowing Daniel's and Julian's assessment of the current state
of things would be good.
> > At a minimum the test failures on Windows would need to be fixed.
> >
> > The easiest path forward we would be to revert the entire change,
> > and then ship 1.14 with a known problem. I still hope that we'll
> > manage to get enough support somehow to actually fix the problem,
> > though I don't know how. I am not going to fix Window-specific bugs
> > myself because I lack a dev environment and don't have any experience
> > with developing on this platform.
>
> My only advice would be to reach a point where we accept no one is going to
> step up and fix this on Windows and then decide accordingly. If we can fix it
> for Linux without making Windows any worse, then I would think we should do
> that. I do not see why we cannot leave the tests failing on Windows. Again,
> as long as we have not made Windows any worse, if some future APR update were
> to make the tests pass that sounds like a good thing.
>
> As long as we know why the tests fail, that seems acceptable to me. If we
> cannot fix Linux without making Windows worse than it is with 1.13 then that
> is different and more complicated for sure.
I cannot really judge the impact on Windows. Apparently, the change
breaks things on Windows because APR's code doesn't work properly there.
Let's wait a bit and see if developers involved will speak up.
> > Sounds like we need to coordinate timing? I am handling the RM side
> > of this, and it would help if I knew at which point in time Mike would
> > no longer be available to help out. Having more people around while we
> > are preparing this release would be great. Fortunately, I am flexible
> > and won't have a problem with moving the date forwards or backwards if
> > that helps.
>
> Sooner is better. I would guess the main area Mike would be able to help
> would be in confirming or improving the Python 3 bindings. As he is updating
> ViewVC and other internal stuff to work with the Py3 bindings he might find
> bugs that he can address.
We also need people to test and sign the releases across OS platforms.
At a minimum there will be 1.14.0-rc1 and 1.14.0 releases to test and sign.
The more people we have around for this, the faster the release can happen.
Re: branching 1.14.x
Posted by Mark Phippard <ma...@gmail.com>.
>
> Nobody is trying to hold up anything. The common goal is to get 1.14
> shipped ASAP. At least I haven't seen anyone saying otherwise.
I know that no one is actively trying to hold up the release, on the contrary we are trying to get it wrapped. I am speaking to the extent these items are still blockers.
I do not fully understand where we are at on shelving. I believe ideas were proposed to make it a compile time feature that would be off by default or something. I am fine with that. You raised it as being a blocker still so I am going off what you wrote. If it was merged and not a blocker then were you just looking for Julian or Daniel or someone else to officially say it is no longer a blocker?
> At a minimum the test failures on Windows would need to be fixed.
>
> The easiest path forward we would be to revert the entire change,
> and then ship 1.14 with a known problem. I still hope that we'll
> manage to get enough support somehow to actually fix the problem,
> though I don't know how. I am not going to fix Window-specific bugs
> myself because I lack a dev environment and don't have any experience
> with developing on this platform.
My only advice would be to reach a point where we accept no one is going to step up and fix this on Windows and then decide accordingly. If we can fix it for Linux without making Windows any worse, then I would think we should do that. I do not see why we cannot leave the tests failing on Windows. Again, as long as we have not made Windows any worse, if some future APR update were to make the tests pass that sounds like a good thing.
As long as we know why the tests fail, that seems acceptable to me. If we cannot fix Linux without making Windows worse than it is with 1.13 then that is different and more complicated for sure.
> Sounds like we need to coordinate timing? I am handling the RM side
> of this, and it would help if I knew at which point in time Mike would
> no longer be available to help out. Having more people around while we
> are preparing this release would be great. Fortunately, I am flexible
> and won't have a problem with moving the date forwards or backwards if
> that helps.
Sooner is better. I would guess the main area Mike would be able to help would be in confirming or improving the Python 3 bindings. As he is updating ViewVC and other internal stuff to work with the Py3 bindings he might find bugs that he can address.
We do have a more pressing project imminent that will be pulling him back. But if the release process starts soon, we would be more likely to allow him to finish so that we will be able to adopt the release once it is official.
Mark
Re: branching 1.14.x
Posted by Mark Phippard <ma...@gmail.com>.
> On Mar 14, 2020, at 11:42 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Stefan Sperling wrote on Sat, 14 Mar 2020 15:00 +0100:
>>> On Sat, Mar 14, 2020 at 09:25:21AM -0400, Mark Phippard wrote:
>>> OK, then let's just move past it and hope it gets fixed in APR? If no one
>>> raises their hand saying they are working on a fix, you should proceed as if
>>> we are never going to fix this in our product. Otherwise, we are just stuck
>>> here in limbo. Security bug or not, if no one is going to fix it then what is
>>> there to wait for?
>>
>> At a minimum the test failures on Windows would need to be fixed.
>>
>> The easiest path forward we would be to revert the entire change,
>> and then ship 1.14 with a known problem. I still hope that we'll
>> manage to get enough support somehow to actually fix the problem,
>> though I don't know how. I am not going to fix Window-specific bugs
>> myself because I lack a dev environment and don't have any experience
>> with developing on this platform.
>
> Reminder: Active Apache committers can apply for MSDN licenses, which
> AIUI include access to Windows VMs.
>
> There are a few Windows build scripts lying around (e.g.,
> tools/dev/windows-build/, tools/dev/build-svn-deps-win.pl, buildbots,
> and that's just in our tree).
These are also a good option if it is just to quickly test/debug something:
https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
They are available to anyone.
Mark
Re: branching 1.14.x
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Sat, 14 Mar 2020 15:00 +0100:
> On Sat, Mar 14, 2020 at 09:25:21AM -0400, Mark Phippard wrote:
> > OK, then let's just move past it and hope it gets fixed in APR? If no one
> > raises their hand saying they are working on a fix, you should proceed as if
> > we are never going to fix this in our product. Otherwise, we are just stuck
> > here in limbo. Security bug or not, if no one is going to fix it then what is
> > there to wait for?
>
> At a minimum the test failures on Windows would need to be fixed.
>
> The easiest path forward we would be to revert the entire change,
> and then ship 1.14 with a known problem. I still hope that we'll
> manage to get enough support somehow to actually fix the problem,
> though I don't know how. I am not going to fix Window-specific bugs
> myself because I lack a dev environment and don't have any experience
> with developing on this platform.
Reminder: Active Apache committers can apply for MSDN licenses, which
AIUI include access to Windows VMs.
There are a few Windows build scripts lying around (e.g.,
tools/dev/windows-build/, tools/dev/build-svn-deps-win.pl, buildbots,
and that's just in our tree).
[Not trying to single out stsp here; just mentioning this for everyone.]
Cheers,
Daniel
Re: branching 1.14.x
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 14, 2020 at 09:25:21AM -0400, Mark Phippard wrote:
> > On Mar 14, 2020, at 8:51 AM, Stefan Sperling <st...@elego.de> wrote:
> > On Sat, Mar 14, 2020 at 08:03:28AM -0400, Mark Phippard wrote:
> > I don't think asking "why are we even doing this" is helpful.
>
> That is pretty unfair. I could go back to say nothing like most of the rest
> of us on this list and leave you all alone wondering why there is no
> response.
> I did not question the work Julian did, I am reflecting the reality of the
> current situation.
Good. Thank you for stating this. I wasn't sure to which degree you
were aware of the amount of the work that's been done here, both in
funded and volunteer capacities.
I'm sorry if my response was too harsh. I felt that the issue of
paid vs. volunteer work needed to be raised to align expectations.
And I didn't mean to imply that you were responsible for any of it.
It's not our fault that investors have moved their money elsewhere.
It's just that I think it's important to recognize the issue and treat
each other accordingly when we voice our expectations of what should
and what shouldn't be done in this project.
> There is currently no path to finishing this feature.
Indeed. The reality is that until more voluntary or paid work can
happen this feature is stuck in development limbo.
> When you find yourself stuck in a hole it is best to quit digging. I know
> some work is being done to hide away the feature so that someone can compile
> it in. If that can be finished great. I am just saying if we cannot get that
> finished, then maybe it is time to delete it or at least have it not compiled
> in and let someone else deal with making it possible to compile it in later.
The 'decouple-shelving-cli' branch has been merged to trunk already.
There could be minor fixups needed for release, but as far as I can
see Julian has already done what he can to unblock the 1.14 release.
> We are holding up some actual value that people need (Python 3 support) so
> that maybe someday someone can come back and finish all of the hard work
> remaining on this shelving feature. If someone really wants to do that, it is
> going to require more new code to be written so I do not see why having the
> experimental feature in 1.14 really helps with that.
Nobody is trying to hold up anything. The common goal is to get 1.14
shipped ASAP. At least I haven't seen anyone saying otherwise.
We are at the point where we need to identify and fix release blockers,
and invariably that will cause delays, in exchange for having less of
a mess to clean up after release.
> Anyway, I am just trying to suggest things to help us get unstuck.
Thanks! I appreciate you taking the time.
FWIW, I am still funded via elego's SVN support to handle releases,
which is what allows me to "volunteer" to wear the RM hat this time
around. Julian has already stated that he can no longer afford this.
> >> I do not fully understand the editor path bug. But if you are saying it
> >> cannot be fixed in an existing release because of API changes, then that
> >> sounds like the priority. Unless Bert has time, I am not sure where we get
> >> Windows help now though.
> >
> > As far as I understand, the problem is that people need to quote their
> > editor commands in certain ways to prevent parts of filenames being
> > interpreted as commands by the shell. This has security implications.
> > See https://svn.apache.org/r1874057
> >
> > The editor command is part of the configuration file. We can't change the
> > quoting rules in a patch release without breaking existing installations
> > because, according to our compatibility guidelines, users should be able
> > to switch freely between patch releases without having to change anything
> > other than the set of binaries they are using.
> >
> > The open problem is that the new quoting code won't work on Windows, even
> > though it is using an APR-provided function to sanitize the filename.
> > From my point of view this is something that should be fixed in APR if
> > possible.
>
> OK, then let's just move past it and hope it gets fixed in APR? If no one
> raises their hand saying they are working on a fix, you should proceed as if
> we are never going to fix this in our product. Otherwise, we are just stuck
> here in limbo. Security bug or not, if no one is going to fix it then what is
> there to wait for?
At a minimum the test failures on Windows would need to be fixed.
The easiest path forward we would be to revert the entire change,
and then ship 1.14 with a known problem. I still hope that we'll
manage to get enough support somehow to actually fix the problem,
though I don't know how. I am not going to fix Window-specific bugs
myself because I lack a dev environment and don't have any experience
with developing on this platform.
> >> Anyway, I have a small window here where I have been able to maybe get our
> >> SVN support updated from 1.8 to a newer version. 1.14 is the only one I am
> >> interested in, so I am hoping the release process starts soon.
> >
> > That is good news! Does this mean you might be able to get some people
> > at CollabNet activated to look at some of the issues we still need to
> > solve before 1.14 can be released?
>
> "people" means Mike at best. He will probably be focused on getting stuff to
> work on Python 3 before we we need him again elsewhere and if the 1.14
> release process does not happen soon then we will probably just have to put
> it all to the side again and hope another window opens up sometime in the
> future.
Sounds like we need to coordinate timing? I am handling the RM side
of this, and it would help if I knew at which point in time Mike would
no longer be available to help out. Having more people around while we
are preparing this release would be great. Fortunately, I am flexible
and won't have a problem with moving the date forwards or backwards if
that helps.
Re: branching 1.14.x
Posted by Mark Phippard <ma...@gmail.com>.
> On Mar 14, 2020, at 12:06 PM, Stefan Sperling <st...@elego.de> wrote:
>
> On Sat, Mar 14, 2020 at 02:16:51PM +0000, Julian Foad wrote:
>> Mark Phippard wrote:
>>> Anyway, I am just trying to suggest things to help us get unstuck.
>>
>> Agreed. Stefan, other readers may read it differently, but I found Mark's
>> input here to be useful and on-topic, as well as bluntly direct. I myself
>> don't take any offence and am not put off by Mark's remarks, in fact I
>> understand and pretty much concur with his view.
>
> OK. That's relieving :) I'm sorry if I came across as confrontational.
>
> I am very happy to see that we do manage to work well together in spite of
> difficulties we have with respect to funding. It does worry me sometimes.
FWIW, I was not offended at all Stefan so no worries. I also appreciate the fact that you are volunteering to RM. I was more concerned with clarifying my remarks and I am mainly looking for ways to help us make decisions and prioritize. It sounds like Julian was able to complete his plan for including this in 1.14 which I am fine with.
Mark
Re: branching 1.14.x
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 14, 2020 at 02:16:51PM +0000, Julian Foad wrote:
> Mark Phippard wrote:
> > Anyway, I am just trying to suggest things to help us get unstuck.
>
> Agreed. Stefan, other readers may read it differently, but I found Mark's
> input here to be useful and on-topic, as well as bluntly direct. I myself
> don't take any offence and am not put off by Mark's remarks, in fact I
> understand and pretty much concur with his view.
OK. That's relieving :) I'm sorry if I came across as confrontational.
I am very happy to see that we do manage to work well together in spite of
difficulties we have with respect to funding. It does worry me sometimes.
Re: branching 1.14.x
Posted by Julian Foad <ju...@apache.org>.
Mark Phippard wrote:
>> Stefan Sperling wrote:
>>>>> 1. The 'decouple-shelving-cli' branch
>>>>> 2. The editor path fixes which don't yet work on Windows.
>>>>> Since nobody has responded: Should I just make a decision by myself?
The 'decouple-shelving-cli' branch is merged and working: the
experimental shelving command line interfaces are hidden unless
explicitly enabled by the user.
I moved the API declarations from /include/ to /include/private/ as part
of that branch.
Because it is experimental, my understanding is we are free to change it
even in patch releases (and if not free in all respects, at least more
free than for stable features).
There is nothing more to do on that than an appropriate mention in the
release notes (which Nathan and Daniel have kindly been doing).
Because of that, the following part of the exchange is rather moot.
>> Mark Phippard wrote:
>>> Personally, I do not care at all about experimental features and shelving. I
>>> would favor ripping it all out and let it come back in a future release if
>>> someone wants to finish and turn it into a feature that we are willing to
>>> support forever. Right now, I cannot foresee a scenario where this feature
>>> ever becomes finished. I do not see why we are even doing the work to include
>>> it. I realize ripping it out would be work that someone has to do too
>>> though.
>>
>> I don't think asking "why are we even doing this" is helpful.
>
> That is pretty unfair. I could go back to say nothing [...]
>
> Anyway, I am just trying to suggest things to help us get unstuck.
Agreed. Stefan, other readers may read it differently, but I found
Mark's input here to be useful and on-topic, as well as bluntly direct.
I myself don't take any offence and am not put off by Mark's remarks, in
fact I understand and pretty much concur with his view.
If there's anything about the current state of the experimental shelving
supports that is getting in the way of a good, stable, 1.14 release, and
if we see that ripping it out (further) is a way to get past that, I
volunteer to do some or all of that ripping work.
That said, as said above I don't see that it is any longer an issue.
>> The editor command is part of the configuration file. We can't change the
>> quoting rules in a patch release [...]
>>
>> The open problem is that the new quoting code won't work on Windows, [...]
>
> OK, then let's just move past it and hope it gets fixed in APR? [...]
Agreed. We do not need to block the release until there is a full
solution including for Windows. We only need non-regression. (I
haven't looked at this issue, so I don't know if the current status is
non-regression. If so, ship it. If not, revert the recent changes.)
- Julian
Re: branching 1.14.x
Posted by Mark Phippard <ma...@gmail.com>.
> On Mar 14, 2020, at 8:51 AM, Stefan Sperling <st...@elego.de> wrote:
>
> On Sat, Mar 14, 2020 at 08:03:28AM -0400, Mark Phippard wrote:
>> Personally, I do not care at all about experimental features and shelving. I
>> would favor ripping it all out and let it come back in a future release if
>> someone wants to finish and turn it into a feature that we are willing to
>> support forever. Right now, I cannot foresee a scenario where this feature
>> ever becomes finished. I do not see why we are even doing the work to include
>> it. I realize ripping it out would be work that someone has to do too
>> though.
>
> I don't think asking "why are we even doing this" is helpful.
That is pretty unfair. I could go back to say nothing like most of the rest of us on this list and leave you all alone wondering why there is no response.
I did not question the work Julian did, I am reflecting the reality of the current situation. There is currently no path to finishing this feature. When you find yourself stuck in a hole it is best to quit digging. I know some work is being done to hide away the feature so that someone can compile it in. If that can be finished great. I am just saying if we cannot get that finished, then maybe it is time to delete it or at least have it not compiled in and let someone else deal with making it possible to compile it in later. We are holding up some actual value that people need (Python 3 support) so that maybe someday someone can come back and finish all of the hard work remaining on this shelving feature. If someone really wants to do that, it is going to require more new code to be written so I do not see why having the experimental feature in 1.14 really helps with that.
Anyway, I am just trying to suggest things to help us get unstuck.
>> I do not fully understand the editor path bug. But if you are saying it
>> cannot be fixed in an existing release because of API changes, then that
>> sounds like the priority. Unless Bert has time, I am not sure where we get
>> Windows help now though.
>
> As far as I understand, the problem is that people need to quote their
> editor commands in certain ways to prevent parts of filenames being
> interpreted as commands by the shell. This has security implications.
> See https://svn.apache.org/r1874057
>
> The editor command is part of the configuration file. We can't change the
> quoting rules in a patch release without breaking existing installations
> because, according to our compatibility guidelines, users should be able
> to switch freely between patch releases without having to change anything
> other than the set of binaries they are using.
>
> The open problem is that the new quoting code won't work on Windows, even
> though it is using an APR-provided function to sanitize the filename.
> From my point of view this is something that should be fixed in APR if
> possible.
OK, then let's just move past it and hope it gets fixed in APR? If no one raises their hand saying they are working on a fix, you should proceed as if we are never going to fix this in our product. Otherwise, we are just stuck here in limbo. Security bug or not, if no one is going to fix it then what is there to wait for?
>> Anyway, I have a small window here where I have been able to maybe get our
>> SVN support updated from 1.8 to a newer version. 1.14 is the only one I am
>> interested in, so I am hoping the release process starts soon.
>
> That is good news! Does this mean you might be able to get some people
> at CollabNet activated to look at some of the issues we still need to
> solve before 1.14 can be released?
"people" means Mike at best. He will probably be focused on getting stuff to work on Python 3 before we we need him again elsewhere and if the 1.14 release process does not happen soon then we will probably just have to put it all to the side again and hope another window opens up sometime in the future.
Mark
Re: branching 1.14.x
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 14, 2020 at 08:03:28AM -0400, Mark Phippard wrote:
> Personally, I do not care at all about experimental features and shelving. I
> would favor ripping it all out and let it come back in a future release if
> someone wants to finish and turn it into a feature that we are willing to
> support forever. Right now, I cannot foresee a scenario where this feature
> ever becomes finished. I do not see why we are even doing the work to include
> it. I realize ripping it out would be work that someone has to do too
> though.
I don't think asking "why are we even doing this" is helpful.
Let's be clear on why this happened: It's because of lack of funding for
Julian and most other developers, who were previously very active and now
have only very little amounts of time they can afford to spend on SVN.
It's not because this feature is a bad idea, or the work that's already
been put in wasn't any useful. It is because developing new features in
our current situation is very difficult. If we still had 1.7 era activity
levels with 10+ active developers, my guess is that the shelving feature
would have long been done and shipped.
To put things in perspective, look at the complexity of the problems
Julian has been dealing with:
https://blog.foad.me.uk/2020/03/02/svn-shelving-development-review/
Now Julian is already doing further voluntary work to address blockers for
the upcoming release. Discouraging this kind of activity now makes things
even worse. It implies we still haven't adjusted our expectations to the
reality that we are doing pure volunteer work. In a project which is
mostly consumed by companies to build products to make money, this new
reality is very hard to swallow. Even slightly pushing volunteer developers
the wrong way could mean losing them entirely.
> I do not fully understand the editor path bug. But if you are saying it
> cannot be fixed in an existing release because of API changes, then that
> sounds like the priority. Unless Bert has time, I am not sure where we get
> Windows help now though.
As far as I understand, the problem is that people need to quote their
editor commands in certain ways to prevent parts of filenames being
interpreted as commands by the shell. This has security implications.
See https://svn.apache.org/r1874057
The editor command is part of the configuration file. We can't change the
quoting rules in a patch release without breaking existing installations
because, according to our compatibility guidelines, users should be able
to switch freely between patch releases without having to change anything
other than the set of binaries they are using.
The open problem is that the new quoting code won't work on Windows, even
though it is using an APR-provided function to sanitize the filename.
From my point of view this is something that should be fixed in APR if
possible.
> Anyway, I have a small window here where I have been able to maybe get our
> SVN support updated from 1.8 to a newer version. 1.14 is the only one I am
> interested in, so I am hoping the release process starts soon.
That is good news! Does this mean you might be able to get some people
at CollabNet activated to look at some of the issues we still need to
solve before 1.14 can be released?
Re: branching 1.14.x
Posted by Mark Phippard <ma...@gmail.com>.
> On Mar 14, 2020, at 7:47 AM, Stefan Sperling <st...@elego.de> wrote:
>
> On Tue, Mar 10, 2020 at 12:23:49PM +0100, Stefan Sperling wrote:
>> As previously discussed, I would like to create the 1.14.x branch
>> soon in order to begin the release process for 1.14.0.
>>
>> There are two changes being worked on which look important and
>> which, I believe, could only be introduced in a dot zero release
>> since they violate our patch release compatibility guarantees:
>>
>> 1. The 'decouple-shelving-cli' branch
>>
>> 2. The editor path fixes which don't yet work on Windows.
>>
>> Did I miss anything?
>>
>> I'm wondering if we should wait with creating the 1.14.x branch
>> until the above changes have settled.
>>
>> Alternatively, we could create the branch now and allow these
>> changes to be merged before 1.14.0; beyond that point these
>> changes could miss the boat and might have to wait until 1.15.
>
> Since nobody has responded: Should I just make a decision by myself? :)
Speaking for myself, it is hard to know whether to respond when you are not really helping and contributing.
The Python3 stuff seems like a big deal to me, and I assume we already missed the next Ubuntu LTS release window because of it. I have to assume SVN in all of the major distros is a real mess today because of this issue.
I'd like to see us get the 1.14 release out there. I thought we left it that this would be the last release unless contributions start to appear that warrant a 1.15 etc.
What should we do? If no one has chimed in they are doing the work then maybe we should branch. We can always merge or rebranch before we release. If it spurs action it would be worth it.
Personally, I do not care at all about experimental features and shelving. I would favor ripping it all out and let it come back in a future release if someone wants to finish and turn it into a feature that we are willing to support forever. Right now, I cannot foresee a scenario where this feature ever becomes finished. I do not see why we are even doing the work to include it. I realize ripping it out would be work that someone has to do too though.
I do not fully understand the editor path bug. But if you are saying it cannot be fixed in an existing release because of API changes, then that sounds like the priority. Unless Bert has time, I am not sure where we get Windows help now though.
Anyway, I have a small window here where I have been able to maybe get our SVN support updated from 1.8 to a newer version. 1.14 is the only one I am interested in, so I am hoping the release process starts soon.
Mark
Re: branching 1.14.x
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Mar 10, 2020 at 12:23:49PM +0100, Stefan Sperling wrote:
> As previously discussed, I would like to create the 1.14.x branch
> soon in order to begin the release process for 1.14.0.
>
> There are two changes being worked on which look important and
> which, I believe, could only be introduced in a dot zero release
> since they violate our patch release compatibility guarantees:
>
> 1. The 'decouple-shelving-cli' branch
>
> 2. The editor path fixes which don't yet work on Windows.
>
> Did I miss anything?
>
> I'm wondering if we should wait with creating the 1.14.x branch
> until the above changes have settled.
>
> Alternatively, we could create the branch now and allow these
> changes to be merged before 1.14.0; beyond that point these
> changes could miss the boat and might have to wait until 1.15.
Since nobody has responded: Should I just make a decision by myself? :)