Stefan Sperling wrote on Thu, 26 Mar 2020 10:18 +0100:
> On Wed, Mar 25, 2020 at 09:56:23PM +0000, Daniel Shahaf wrote:
> > Nathan Hartman wrote on Wed, 25 Mar 2020 17:30 -0400:
> > > FYI, I tested 1.14.0-rc1 today, but I'm not rushing to sign (yet)
> > > because I'm waiting to see if we'll get Denis's patch (or a later
> > > version of it) into 1.14.
>
> I don't see any reason to wait with adding your signature.
> More below.
>
> > > I tested *without* Denis's patch, but I'll test again with it and keep
> > > the list posted.
> >
> > What kind of tests do you have in mind? Denis's patch has virtually
> > zero interaction with existing tests, so a 'make check' run wouldn't
> > teach us much, IMO: it wouldn't run the new code at all, other than the
> > newly-added test itself. On the other hand, running the new subcommand
> > on a repository as it's receiving commits would be interesting.
>
> Yes, that's what I had in mind when I said it's a low risk change.
>
> A full test run after every change is of course prudent but I doubt adding
> this patch will cause us any problems or regressions in the release itself.
>
> The patch will first have to pass through testing on trunk. It will be
> tested by our buildbots, and by Denis, and by developers handling the patch.
> And at this point in time the trunk code is virtually identical to 1.14.0.
>
> More likely, rushing a patch such as this one into a .0 release could mean
> that we'll find problems in the new feature after it is first released,
> rather than shipping it in a known-perfect state.
> But that's fine. It's what patch releases are for :)
I'm not worried about bugs in the new feature. If a bug slips past all
our layers of review and testing, we'll fix it in .1, as you say.
What I'm worried about is that we'll apply the "backwards compatibility
until 2.0" promise to something we shouldn't. As I said, issues of
this nature can't generally be found by tests; they can only be found
by code review.
Cheers,
Daniel
Received on 2020-03-26 21:32:47 CET