On Sat, Mar 14, 2020 at 09:25:21AM -0400, Mark Phippard wrote:
> > On Mar 14, 2020, at 8:51 AM, Stefan Sperling <stsp_at_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.
Received on 2020-03-14 15:00:32 CET