Re: Time to branch 1.9

[Branko Čibej <br...@wandisco.com>]

On 16.01.2015 11:06, Branko Čibej wrote:
> A couple months down the line, and I'd like to make another call for
> creating the 1.9 release branch. AFAICS the x509 branch still needs
> merging if we want it in 1.9 (which I think we do, since IIUC trunk
> currently does not handle all certs correctly).
>
> Anything else?
>
> I'd like to propose that we cut the branch and roll an RC (or a beta) in
> a couple weeks.

All right, it's been three weeks. During this time some massive code
churn has happened on trunk, and a couple branches (pin-externals and
reuse-ra-session) are assumed to be merge candidates for this release.

None of the above is really necessary for a 1.9 release, but since it's
here, let's please stabilize trunk for the branch. I propose this means:

  * Do not begin any more massive changes on trunk; take them to a branch.
  * Finish whatever you're doing and concentrate on bug fixes and
    stabilization.
  * Propose branch reviews/merge votes ASAP.

The latest last-minute changes introduced a heisencrash in ra-test, and
made some C tests run via DAV look for global credentials (e.g., the
keychain on the Mac). I haven't tracked these down yet, but surely we
can keep trunk more stable than that.

If there are no objections, I'd like to set the target date for creating
the 1.9 branch to a week from today. Further last-minute changes can
wait for 1.10; 1.9 is rapidly becoming the slowest release ever.

-- Brane

Re: Time to branch 1.9

[Branko Čibej <br...@wandisco.com>]

On 09.02.2015 11:11, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> The latest last-minute changes introduced a heisencrash in ra-test, and
>> made some C tests run via DAV look for global credentials (e.g., the
>> keychain on the Mac). I haven't tracked these down yet, but surely we
>> can keep trunk more stable than that.
> Does the ra-test crash happen in --parallel mode only?  Running C tests
> in parallel is new and ra-test.c doesn't follow the rules for calling
> svn_ra_initialize: there is no protection against concurrent calls and
> the pool passed has the wrong lifetime.

It turns out that it's not a crash. It also turns out that it's not new.
The test hangs deep in BDB within cleanup-fs during the destruction of
the top-level pool; but not always. The following script consistently
reproduces this for me on trunk:

cd $(builddir)/subversion/tests/cmdline
while ../libsvn_ra/ra-test --fs-type=bdb; do echo '-----'; done


It usually takes a few iterations, but it will fail eventually during
cleanup for test #3. It's specific to BDB, and it could be specific to OSX.

I verified that this is not new by building a version of trunk from
three months ago; same issue. I'm just surprised we haven't seen it
before (hence the suspicion that it's OSX-only).

-- Brane

Re: Time to branch 1.9

[Philip Martin <ph...@codematters.co.uk>]

Philip Martin <ph...@wandisco.com> writes:

> Branko Čibej <br...@wandisco.com> writes:
>
>> The latest last-minute changes introduced a heisencrash in ra-test, and
>> made some C tests run via DAV look for global credentials (e.g., the
>> keychain on the Mac). I haven't tracked these down yet, but surely we
>> can keep trunk more stable than that.
>
> Does the ra-test crash happen in --parallel mode only?  Running C tests
> in parallel is new and ra-test.c doesn't follow the rules for calling
> svn_ra_initialize: there is no protection against concurrent calls and
> the pool passed has the wrong lifetime.

That can't be the cause of the crash, svn_ra_initialize doesn't yet do
anything.

-- 
Philip

Re: Time to branch 1.9

[Philip Martin <ph...@wandisco.com>]

Branko Čibej <br...@wandisco.com> writes:

> The latest last-minute changes introduced a heisencrash in ra-test, and
> made some C tests run via DAV look for global credentials (e.g., the
> keychain on the Mac). I haven't tracked these down yet, but surely we
> can keep trunk more stable than that.

Does the ra-test crash happen in --parallel mode only?  Running C tests
in parallel is new and ra-test.c doesn't follow the rules for calling
svn_ra_initialize: there is no protection against concurrent calls and
the pool passed has the wrong lifetime.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: Time to branch 1.9

[Branko Čibej <br...@wandisco.com>]

On 09.02.2015 16:44, Julian Foad wrote:
> Branko Čibej wrote:
>> All right, it's been three weeks. During this time some massive code
>> churn has happened on trunk, and a couple branches (pin-externals and
>> reuse-ra-session) are assumed to be merge candidates for this release.
>>
>> None of the above is really necessary for a 1.9 release, but since it's
>> here, let's please stabilize trunk for the branch.
> I'd like to say something 
> stronger. It would be lovely if those pieces of work that are still in progress on branches get released in 1.9, and I hope they will, but let's not fall into the old trap of starting with an assumption that they will. Rather, let us start with the assumption that 1.9 will be released 5 weeks from today, and start concentrating right now on the activities needed to achieve that. If the work-in-progress gets included as well, that's great, but we all know from experience that work that seems to be nearly finished nearly always isn't.

Agreed. I'm now working writing down a formalized description of the
release process we talked about in Berlin back in 2013, in such a way
that it should help us plan development and releases better. In the
certain (though forlorn) hope that we can actually release 1.10 about 6
months after 1.9.

Pending consensus about the process, of course.

-- Brane

Re: Time to branch 1.9

[Julian Foad <ju...@btopenworld.com>]

Branko Čibej wrote:
> All right, it's been three weeks. During this time some massive code
> churn has happened on trunk, and a couple branches (pin-externals and
> reuse-ra-session) are assumed to be merge candidates for this release.
> 
> None of the above is really necessary for a 1.9 release, but since it's
> here, let's please stabilize trunk for the branch.

I'd like to say something 
stronger. It would be lovely if those pieces of work that are still in progress on branches get released in 1.9, and I hope they will, but let's not fall into the old trap of starting with an assumption that they will. Rather, let us start with the assumption that 1.9 will be released 5 weeks from today, and start concentrating right now on the activities needed to achieve that. If the work-in-progress gets included as well, that's great, but we all know from experience that work that seems to be nearly finished nearly always isn't.


> I propose this means:
> 
>   * Do not begin any more massive changes on trunk; take them to a branch.
>   * Finish whatever you're doing and concentrate on bug fixes and
>     stabilization.
>   * Propose branch reviews/merge votes ASAP.
[...]
> If there are no objections, I'd like to set the target date for creating
> the 1.9 branch to a week from today. [...]

+1.

- Julian