1.10.0-alpha1 is up for signing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

1.10.0-alpha1 is up for signing

Stefan Sperling-9
The 1.10.1-alpha1 release is finally up for signing.

Full committers, please get this release from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there.

Thank you!
Reply | Threaded
Open this post in threaded view
|

Re: 1.10.0-alpha1 is up for signing

Stefan Sperling-9
On Thu, Feb 16, 2017 at 03:26:58PM +0100, Stefan Sperling wrote:
> The 1.10.1-alpha1 release is finally up for signing.

Sorry about the above typo.
The subject line has the correct release number (1.10.0-alpha1).
Reply | Threaded
Open this post in threaded view
|

Enabling FSFS debug code in alpha releases (was: Re: 1.10.0-alpha1 is up for signing)

Daniel Shahaf-2
In reply to this post by Stefan Sperling-9
A couple of weeks ago we discussed enabling
verify_as_revision_before_current_plus_plus() in the alpha release.

Since that hasn't been done yet, the alpha is now tagged without that
change.  (I do not fault him stsp that in the least; the onus was on
proponents of the change to make it happen.)

Can we arrange for a future pre-release (1.10.0-alpha2 or 1.10.0-beta1)
to include this change?

The patch is trivial (attached), so I think this really is about the
mechanics of making the change; for example:

1) enabling it on trunk permanently (and disabling it on stable branches)

2) tagging a wc that has the patch applied

3) committing the patch to a branch and <handwave>arrange for the tag to
incorporate the changes from that branch</handwave>.

Once we resolve this trivial process issue, we'll be able to get user
feedback for verify_as_revision_before_current_plus_plus().

Cheers,

Daniel

Stefan Sperling wrote on Thu, Feb 16, 2017 at 15:26:58 +0100:
> The 1.10.1-alpha1 release is finally up for signing.
>
> Full committers, please get this release from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thank you!
>

[[[
Index: subversion/libsvn_fs_fs/transaction.c
===================================================================
--- subversion/libsvn_fs_fs/transaction.c (revision 1783170)
+++ subversion/libsvn_fs_fs/transaction.c (working copy)
@@ -3338,7 +3342,7 @@ verify_as_revision_before_current_plus_plus(svn_fs
                                             svn_revnum_t new_rev,
                                             apr_pool_t *pool)
 {
-#ifdef SVN_DEBUG
+#if 1
   fs_fs_data_t *ffd = fs->fsap_data;
   svn_fs_t *ft; /* fs++ == ft */
   svn_fs_root_t *root;
]]]
Reply | Threaded
Open this post in threaded view
|

Re: 1.10.0-alpha1 is up for signing

Stefan Sperling-9
In reply to this post by Stefan Sperling-9
On Thu, Feb 16, 2017 at 03:26:58PM +0100, Stefan Sperling wrote:
> The 1.10.1-alpha1 release is finally up for signing.
>
> Full committers, please get this release from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thank you!

I just realized I did not include my own test results and dependencies.
So here they are:

Tested: [bdb | fsfs] x [ra_local | ra_svn | ra_serf]
        swig bindings
        javahl bindings

Test results: All passed.

Platform: OpenBSD 6.0 amd64

Dependencies:
bdb:        4.7.25
GNU-iconv:  1.15
apr:        1.5.2
apr-util:   1.5.4
httpd:      2.2.32
serf:       1.3.9
cyrus-sasl: 2.1.25
sqlite:     3160200
libssl:     LibreSSL 2.5.1
swig:       2.0.11
python:     2.7.13
perl:       5.24.1
ruby:       2.1.10
java:       1.7.0_80
Reply | Threaded
Open this post in threaded view
|

Re: Enabling FSFS debug code in alpha releases (was: Re: 1.10.0-alpha1 is up for signing)

Stefan Sperling
In reply to this post by Daniel Shahaf-2
On Thu, Feb 16, 2017 at 02:47:48PM +0000, Daniel Shahaf wrote:
> The patch is trivial (attached), so I think this really is about the
> mechanics of making the change; for example:
>
> 1) enabling it on trunk permanently (and disabling it on stable branches)
>
> 2) tagging a wc that has the patch applied
>
> 3) committing the patch to a branch and <handwave>arrange for the tag to
> incorporate the changes from that branch</handwave>.

4) Encourage people to compile alpha/beta/rc with --enable-maintainer-mode.

That would enable the change under discussion, would it not?
This also makes sense for other reasons, e.g. errors reported back to us
will contain proper backtraces, etc.
Reply | Threaded
Open this post in threaded view
|

Re: Enabling FSFS debug code in alpha releases (was: Re: 1.10.0-alpha1 is up for signing)

Evgeny Kotkov
Stefan Sperling <[hidden email]> writes:

>> 1) enabling it on trunk permanently (and disabling it on stable branches)
>>
>> 2) tagging a wc that has the patch applied
>>
>> 3) committing the patch to a branch and <handwave>arrange for the tag to
>> incorporate the changes from that branch</handwave>.
>
> 4) Encourage people to compile alpha/beta/rc with --enable-maintainer-mode.

4) seems like an appropriate option to me.

This is because we only ship the source code, and I think that those who
actually build it should be in charge of enabling or disabling the debug
features.


Regards,
Evgeny Kotkov
Reply | Threaded
Open this post in threaded view
|

Re: Enabling FSFS debug code in alpha releases (was: Re: 1.10.0-alpha1 is up for signing)

Daniel Shahaf-2
Evgeny Kotkov wrote on Thu, Feb 16, 2017 at 23:55:19 +0300:

> Stefan Sperling <[hidden email]> writes:
>
> >> 1) enabling it on trunk permanently (and disabling it on stable branches)
> >>
> >> 2) tagging a wc that has the patch applied
> >>
> >> 3) committing the patch to a branch and <handwave>arrange for the tag to
> >> incorporate the changes from that branch</handwave>.
> >
> > 4) Encourage people to compile alpha/beta/rc with --enable-maintainer-mode.
>
> 4) seems like an appropriate option to me.
>
> This is because we only ship the source code, and I think that those who
> actually build it should be in charge of enabling or disabling the debug
> features.

So perhaps we should change the guard from
.
    #ifdef SVN_DEBUG
.
to
.
    #if defined(SVN_DEBUG) || defined(FSFS_VERIFY_AS_REVISION_BEFORE_CURRENT_PLUS_PLUS)
.
to make it easier to enable that one feature, without everything else
that maintainer mode brings.

Cheers,

Daniel
(and if we choose #4, we should document that somewhere — release notes
or release announcement or something)
Reply | Threaded
Open this post in threaded view
|

Re: Enabling FSFS debug code in alpha releases (was: Re: 1.10.0-alpha1 is up for signing)

Stefan Sperling
On Fri, Feb 17, 2017 at 06:43:41AM +0000, Daniel Shahaf wrote:

> Evgeny Kotkov wrote on Thu, Feb 16, 2017 at 23:55:19 +0300:
> > Stefan Sperling <[hidden email]> writes:
> >
> > >> 1) enabling it on trunk permanently (and disabling it on stable branches)
> > >>
> > >> 2) tagging a wc that has the patch applied
> > >>
> > >> 3) committing the patch to a branch and <handwave>arrange for the tag to
> > >> incorporate the changes from that branch</handwave>.
> > >
> > > 4) Encourage people to compile alpha/beta/rc with --enable-maintainer-mode.
> >
> > 4) seems like an appropriate option to me.
> >
> > This is because we only ship the source code, and I think that those who
> > actually build it should be in charge of enabling or disabling the debug
> > features.
>
> So perhaps we should change the guard from
> .
>     #ifdef SVN_DEBUG
> .
> to
> .
>     #if defined(SVN_DEBUG) || defined(FSFS_VERIFY_AS_REVISION_BEFORE_CURRENT_PLUS_PLUS)
> .
> to make it easier to enable that one feature, without everything else
> that maintainer mode brings.

Why are you concerned about everything else that maintainer mode brings?
I use it all the time and don't notice any problem. Which problems do you
expect for end users if they use maintainer mode?

Additional knobs like this cause additional clutter and forces packagers
to sort through them all and figure out which combo they want.
Granted, we have a lot of specific feature compile time knobs already,
but that in itself is not a good reason for adding more of them.

I think it is entirely reasonable for us, in general and regardless of this
particular revision++ check, to ask users to enable maintainer mode when
testing alpha and betas.

> (and if we choose #4, we should document that somewhere — release notes
> or release announcement or something)

Of course -- BTW, the release notes aren't done yet; Could anyone help
me with going over CHANGES and creating sections in the release notes
for new features worth highlighting (new subcommands, options, etc.)? :-)
Reply | Threaded
Open this post in threaded view
|

Re: Enabling FSFS debug code in alpha releases (was: Re: 1.10.0-alpha1 is up for signing)

Daniel Shahaf-2
Stefan Sperling wrote on Fri, Feb 17, 2017 at 10:05:23 +0100:

> On Fri, Feb 17, 2017 at 06:43:41AM +0000, Daniel Shahaf wrote:
> > Evgeny Kotkov wrote on Thu, Feb 16, 2017 at 23:55:19 +0300:
> > > > 4) Encourage people to compile alpha/beta/rc with --enable-maintainer-mode.
> > >
> > > 4) seems like an appropriate option to me.
> > >
> > > This is because we only ship the source code, and I think that those who
> > > actually build it should be in charge of enabling or disabling the debug
> > > features.
> >
> > So perhaps we should change the guard from
> > .
> >     #ifdef SVN_DEBUG
> > .
> > to
> > .
> >     #if defined(SVN_DEBUG) || defined(FSFS_VERIFY_AS_REVISION_BEFORE_CURRENT_PLUS_PLUS)
> > .
> > to make it easier to enable that one feature, without everything else
> > that maintainer mode brings.
>
> Why are you concerned about everything else that maintainer mode brings?
> I use it all the time and don't notice any problem. Which problems do you
> expect for end users if they use maintainer mode?

Two reasons.

a) On general principles, if we want users to test verify-before-commit,
that is not a reason to enable everything else maintainer mode brings.
Kill a fly with a flyswat, not with a cannon.

b) Testing alphas/betas without maintainer mode means the tested code is
closer to what would be compiled from an eventual release.  (We've all
seen bugs that happen only in debug builds, or only in release builds.)

I realize that there are also good reason to enable maintainer mode when
testing betas.  I don't mean to open that bikeshed; only to point out
that "release build with verify-before-commit" is a reasonable configuration.

> Additional knobs like this cause additional clutter and forces packagers
> to sort through them all and figure out which combo they want.
> Granted, we have a lot of specific feature compile time knobs already,

... which is why we have notes/knobs enumerating them.

> but that in itself is not a good reason for adding more of them.
>
> I think it is entirely reasonable for us, in general and regardless of this
> particular revision++ check, to ask users to enable maintainer mode when
> testing alpha and betas.

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling FSFS debug code in alpha releases

Branko Čibej
In reply to this post by Daniel Shahaf-2
On 17.02.2017 07:43, Daniel Shahaf wrote:

> Evgeny Kotkov wrote on Thu, Feb 16, 2017 at 23:55:19 +0300:
>> Stefan Sperling <[hidden email]> writes:
>>
>>>> 1) enabling it on trunk permanently (and disabling it on stable branches)
>>>>
>>>> 2) tagging a wc that has the patch applied
>>>>
>>>> 3) committing the patch to a branch and <handwave>arrange for the tag to
>>>> incorporate the changes from that branch</handwave>.
>>> 4) Encourage people to compile alpha/beta/rc with --enable-maintainer-mode.
>> 4) seems like an appropriate option to me.
>>
>> This is because we only ship the source code, and I think that those who
>> actually build it should be in charge of enabling or disabling the debug
>> features.
> So perhaps we should change the guard from
> .
>     #ifdef SVN_DEBUG
> .
> to
> .
>     #if defined(SVN_DEBUG) || defined(FSFS_VERIFY_AS_REVISION_BEFORE_CURRENT_PLUS_PLUS)
> .
> to make it easier to enable that one feature, without everything else
> that maintainer mode brings.


--enable-debug and --enable-maintainer-mode are separate flags. Not
quite orthogonal, but separate.

-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: 1.10.0-alpha1 is up for signing

Johan Corveleyn-3
In reply to this post by Stefan Sperling-9
On Thu, Feb 16, 2017 at 3:26 PM, Stefan Sperling <[hidden email]> wrote:
> The 1.10.1-alpha1 release is finally up for signing.
>
> Full committers, please get this release from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thank you!

Summary
-------
+1 to release

Platform
--------
Windows 7 SP1 (x64)
Microsoft Visual Studio 2013

Verified
--------
Signature and sha1 for subversion-1.10.0-alpha1.zip.

Contents of subversion-1.10.0-alpha1.zip are identical to tags/1.10.0-alpha1,
and to trunk@1783214 (except for expected differences in svn_version.h
and svnpubsub, svnwcsub and nominate.pl (symlinks vs. file contents), and
generated files).

Tested
------
[ Release build ] x [ fsfs ] x [ file | svn | http ]

Results
-------
All tests pass, except patch #69 (add and remove executable file) because
it tickles the antivirus. This is a known test-suite issue,
see https://svn.haxx.se/dev/archive-2017-01/0075.shtml.

Dependencies
------------
Httpd 2.4.16
Apr 1.5.2
Apr-Util 1.5.4
OpenSSL 1.0.2
Serf 1.3.8
SQLite 3.8.8.3
ZLib 1.2.8

Signature
---------

subversion-1.10.0-alpha1.zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABCgAGBQJYqOaKAAoJELWc5tYBDIqtvGsQAJB+gGWlhJ40A1mjQ0GV+mTq
l4xBDneKhgvucgOpuMQzXaPiIf10Ob3xP4md0gZKoMuxwRGmNpg3xDijEjaDFLMM
FUYxb7DSKVyF2HLLwQAec9Dq+ri3FtfVCwntNxWW8RNmnWkTOWKZ398pb3YyOZ6J
dc1Q7keGQ1Pkvdhd3KOYW5OiiU1L9q26Op7qB1MpQTfgUIEnaziVryUnLL7F0+r/
iAAUTF7wlo2BJRirCEfUpBVJ/zLcRbFICW4Yk3S7PhwzST4HcMhtIPOZ77HX55nu
YNPvNlutUzv4zVDkym4qSx1O5NhWCo1uvIryU6e7K+tFCh0FtRUZ6j2yg8tfL6eO
CxjrXYiX2LnEcd9VBnNo9ILb50ZM+nNhMc3jS08WgPdLSXYUv0AGj/TUyAkomXAZ
uVu8iNvOhivpsvY4V1bP5kGKOJ+dn9aonWtXRnirJZkVGcXRPPqed+Bn7B3Gn6AY
KXniK9aDpVq4TPoPgYIm+CI1mqZrOSqH/Tnnd6/CbDUtRiXvJgnxMU1XPL2WbniQ
+5Ml+W9h1PwSED3tgwFoUa58G3+aREFizp9PoJpVOjZB5CK7GaCvwxg8Lul3H3ow
SYlxqFXgER84m5fQVIa2w3U1CKhKg0wg5AAugGltssGI91Gi7vFhhsZzgZRca8K0
TU2jhPD5y5sPCPCBGnc+
=G9Kk
-----END PGP SIGNATURE-----

--
Johan
Reply | Threaded
Open this post in threaded view
|

Re: 1.10.0-alpha1 is up for signing

Stefan
In reply to this post by Stefan Sperling-9
On 2/16/2017 15:26, Stefan Sperling wrote:
> The 1.10.1-alpha1 release is finally up for signing.
>
> Full committers, please get this release from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thank you!

Trying to build this release triggers the following build error when
compiling the svn-mergeinfo-normalizer tool for me:

..\..\..\tools\client-side\svn-mergeinfo-normalizer\wc_mergeinfo.c(376):
error C4013: 'svn_hash__sets' undefined; assuming extern returning int [
G:\Projekte\MaxSVN\1.10.0-alpha1\build\win32\vcnet-vcproj\svn-mergeinfo-normalizer.vcxproj]

If I'm not mistaken, the issue got introduced in r1777345 where
svn_hash__sets() is used now. However, svn_has__sets() is only declared
(in svn_hash.h ln251 ff.) if SVN_HASH__GETS_SETS is defined (which atm
is only the case, if SVN_DEBUG is defined). That currently breaks the
release build of that tool for me.

Should this issue be fixed before alpha1 is released (assuming it's not
an issue on my side)?

Regards,
Stefan



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 1.10.0-alpha1 is up for signing

Evgeny Kotkov
Stefan Hett <[hidden email]> writes:

> Trying to build this release triggers the following build error when
> compiling the svn-mergeinfo-normalizer tool for me:
>
> ..\..\..\tools\client-side\svn-mergeinfo-normalizer\wc_mergeinfo.c(376):
> error C4013: 'svn_hash__sets' undefined; assuming extern returning int

I can confirm that 1.10.0-alpha1 doesn't build on Windows in my environment
(the svn-mergeinfo-normalizer tool is built by default).

I committed r1783859 and r1783862 in order to fix this issue.  Perhaps, we
should roll alpha2 with these fixes?


Regards,
Evgeny Kotkov
Reply | Threaded
Open this post in threaded view
|

Re: 1.10.0-alpha1 is up for signing

Stefan Sperling-9
On Tue, Feb 21, 2017 at 01:18:01PM +0300, Evgeny Kotkov wrote:

> Stefan Hett <[hidden email]> writes:
>
> > Trying to build this release triggers the following build error when
> > compiling the svn-mergeinfo-normalizer tool for me:
> >
> > ..\..\..\tools\client-side\svn-mergeinfo-normalizer\wc_mergeinfo.c(376):
> > error C4013: 'svn_hash__sets' undefined; assuming extern returning int
>
> I can confirm that 1.10.0-alpha1 doesn't build on Windows in my environment
> (the svn-mergeinfo-normalizer tool is built by default).
>
> I committed r1783859 and r1783862 in order to fix this issue.  Perhaps, we
> should roll alpha2 with these fixes?
>
>
> Regards,
> Evgeny Kotkov

Thanks for fixing this Evgeny!

I agree we should prepare another release and toss alpha1, given that
alpha1 does not compile everywhere. I'll do that today.
Reply | Threaded
Open this post in threaded view
|

RE: 1.10.0-alpha1 is up for signing

Bert Huijben-5

If you compare this problem to 1.7 or something it wouldn’t be a regression.

 

MSBuild by default builds all targets in the makefile, if you don’t pass a target via the optional -t argument. In those older versions we always generated targets that depended hard on optional dependencies, so building everything didn’t work… You really had to specify a target like __ALL_TESTS__, to avoid things like the swig code, bdb or cxxhl failing.

 

Since that problem was fixed some time ago, we now fail on systems that just build everything… while those that still specify a target like our buildbots that were setup to be compatible with those old setups don’t see this problem.

 

Note that I don’t think the unix makefiles build everything either… so they may have similar problems somewhere.

 

But +1 on rerolling anyway.

 

 

Bert

 

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: dinsdag 21 februari 2017 11:28
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: 1.10.0-alpha1 is up for signing

 

On Tue, Feb 21, 2017 at 01:18:01PM +0300, Evgeny Kotkov wrote:

> Stefan Hett <[hidden email]> writes:

>

> > Trying to build this release triggers the following build error when

> > compiling the svn-mergeinfo-normalizer tool for me:

> >

> > ..\..\..\tools\client-side\svn-mergeinfo-normalizer\wc_mergeinfo.c(376):

> > error C4013: 'svn_hash__sets' undefined; assuming extern returning int

>

> I can confirm that 1.10.0-alpha1 doesn't build on Windows in my environment

> (the svn-mergeinfo-normalizer tool is built by default).

>

> I committed r1783859 and r1783862 in order to fix this issue.  Perhaps, we

> should roll alpha2 with these fixes?

>

>

> Regards,

> Evgeny Kotkov

 

Thanks for fixing this Evgeny!

 

I agree we should prepare another release and toss alpha1, given that

alpha1 does not compile everywhere. I'll do that today.

 

Reply | Threaded
Open this post in threaded view
|

Re: 1.10.0-alpha1 is up for signing

Johan Corveleyn-3
On Tue, Feb 21, 2017 at 5:29 PM,  <[hidden email]> wrote:

> If you compare this problem to 1.7 or something it wouldn’t be a regression.
>
>
>
> MSBuild by default builds all targets in the makefile, if you don’t pass a
> target via the optional -t argument. In those older versions we always
> generated targets that depended hard on optional dependencies, so building
> everything didn’t work… You really had to specify a target like
> __ALL_TESTS__, to avoid things like the swig code, bdb or cxxhl failing.
>
>
>
> Since that problem was fixed some time ago, we now fail on systems that just
> build everything… while those that still specify a target like our buildbots
> that were setup to be compatible with those old setups don’t see this
> problem.

Ah, that explains why I didn't see this problem. I built the
__ALL_TESTS__ target.

Thanks for pointing that out, Bert ... I was a little puzzled.

--
Johan