You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2014/03/04 10:23:10 UTC
1.9.0-alpha2 up for testing/signing
The 1.9.0-alpha2 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there. There's no particular schedule to this it's
ready when it's ready.
Thanks!
RE: 1.9.0-alpha2 up for testing/signing
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ben Reser [mailto:ben@reser.org]
> Sent: dinsdag 4 maart 2014 10:23
> To: Subversion Development
> Subject: 1.9.0-alpha2 up for testing/signing
>
> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. There's no particular schedule to this
it's
> ready when it's ready.
+1 for release as alpha version.
(Still too many known XFails and issues for a true release as non-alpha)
I ran the usual tests [bdb | fsfs] x [local | svnserve | serf] and confirmed
that the buildscripts are compatible with the different build variants for
SlikSvn, SharpSvn, etc.
apr 1.5.0
apr-util 1.5.3
db 4.4.20
expat 2.0.1
httpd 2.4.7
java-sdk 1.7.0_45
mod_dav 2.4.7
openssl 1.0.1f
sasl 2.1.25
sqlite 3.8.3.1
zlib 1.2.8
Bert
Re: 1.9.0-alpha2 up for testing/signing
Posted by "Alagazam.net Subversion" <sv...@alagazam.net>.
On 2014-03-31 19:25, Ben Reser wrote:
> On 3/4/14, 1:23 AM, Ben Reser wrote:
>> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
>> Please get the tarballs from
>> https://dist.apache.org/repos/dist/dev/subversion
>> and add your signatures there. There's no particular schedule to this it's
>> ready when it's ready.
>
> All we need is one Windows vote (and have since the 19th). Can someone please
> take a little bit of time to vote for Windows? Ivan or Mark you guys out there?
>
FWIW without me having any vote...
I gave it a go trying to build and run the test suite using my build
environment for Win32SVN.
It took some time and some compile error patching to make it build in
VC++6, but eventually I got the test suite running, and it did with all
test pass ;-)
Platform:
---------
Windows XP SP3
Microsoft Visual Studio 6.0
Tested:
-------
Release build
[fsfs | bdb] x file
fsfs x [svn | http]
Binding NOT tested
Dependencies:
-------------
APR 1.5.0
APR-util 1.5.3
APR-ICONV 1.2.1
Berkeley DB 4.8.30
OpenSSL 1.0.1f
ZLib 1.2.8
Apache 2.4.7
PCRE 8.34
Python 2.7.6
Perl 5.16.3 (ActivePerl)
libintl 0.14.1 (patched)
Java 1.7.0_51
Ruby 1.8.6
Cyrus SASL 2.1.23
serf 1.3.4
sqlite 3.8.3.1
SWIG 1.3.40
Best regards
David Darj (a.k.a. Alagazam)
Maintainer of Win32SVN
http://alagazam.net
Re: 1.9.0-alpha2 up for testing/signing
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Mar 31, 2014 at 1:25 PM, Ben Reser <be...@reser.org> wrote:
> On 3/4/14, 1:23 AM, Ben Reser wrote:
> > The 1.9.0-alpha2 release artifacts are now available for testing/signing.
> > Please get the tarballs from
> > https://dist.apache.org/repos/dist/dev/subversion
> > and add your signatures there. There's no particular schedule to this
> it's
> > ready when it's ready.
>
> All we need is one Windows vote (and have since the 19th). Can someone
> please
> take a little bit of time to vote for Windows? Ivan or Mark you guys out
> there?
>
I've let my Windows setup rot, so not setup to build at the moment. I
could do some kind of compare of the zip with the tag but a Unix dev could
do that and sign the zip too.
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: 1.9.0-alpha2 up for testing/signing
Posted by Branko Čibej <br...@wandisco.com>.
On 07.04.2014 05:08, Julian Foad wrote:
> Here's a thought about what to do with this alpha release.
>
> Part of Ivan's concern is the maintenance burden and the stability of the FSFS changes, and alpha testing will not really help us to reveal or understand those issues. While we discuss those issues in a separate thread, I would suggest that if alpha testing does not reveal any issues related to stability or maintenance of the server, then we learn nothing about the server changes, but that does not reduce the usefulness of the alpha testing in providing feedback about *other* changes.
For the alpha2 we're discussing, we more or less know that there are
bugs in FSFS ... after all, a number of them have been fixed in the 5
weeks since the release tarball was created.
But that's perfectly fine, IMO; the reason why we decided to produce
alpha and beta packages was to increase the chances of getting feedback
before the code and features are more or less cast in concrete with RC1.
And I at least fully expect to find obvious bugs in alpha and beta
releases; even bugs that would be considered release blockers in other
circumstances.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: 1.9.0-alpha2 up for testing/signing
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Reser wrote:
> [...] given that we need 3 Windows votes and the only person
> that seems to have a functional Windows setup who could vote right now seems to
> be you.
>
> Given our current policies that's essentially placing you in the position of
> being able to veto moving forward with this.
No, that's not fair. Don't imply that Ivan is to blame for our lack of test signatures.
[...]
>> I've raised my concerns again on mailing list:
>>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201311.mbox/%3CCABw-3YdV1YX0yU3cuWD8syPGpQxkLBUe=6h_bMkuBfA+vQf9XA@mail.gmail.com%3E
>>
>> I think we shouldn't change FSFS disk format at least in Subversion
>> 1.9.0, before we get some feedback about FSX ideas from the wild.
>> Because we can fix almost any bug in future, but it's extremely costly
>> to deal with on disk format mistakes.
>>
>> But log-addressing branch was pushed to trunk.
>
> Okay I did forget about this conversation. But you seemed to be ok with
> improved testing. [...] why [...] Why [...] Why did you not bring this
> up when 1.9.0-alpha1 was being prepared to release?
I understand your frustration, Ben, but I don't think it's helpful to nag Ivan about why he didn't continue to push his concerns in the past.
Can we do two things at once? (1) Discuss what level of stability of FSFS we should eventually release in 1.9, in a *separate email thread*; and ...
>> My opinion on Subversion 1.9.0 is the following: release Subversion
>> 1.9.0 ASAP without FSFS format change. We have many FSFS performance
>> improvements in trunk that doesn't require format change.
>>
>> I think that cost of maintaining disk format backward compatibility
>> and code destabilization doesn't worth the real benefits that users
>> get from fsfs7 performance improvements. On the other side: if
>> log-addressing and related stuff are so cool and rock-solid, users
>> always can switch to FSX and fully benefit from this new stuff.
>
[...]
> What exactly do we need to do to make you happy with a 1.9.0-alpha release? Is
> there anything we can do? Is removing the format 7 code enough? Or if that
> was removed would you still be against it since you don't think it's
> useful?
>
> Bottom line, what do you want to do here?
... also (2) Decide what to do in the short term with this alpha release.
Here's a thought about what to do with this alpha release.
Part of Ivan's concern is the maintenance burden and the stability of the FSFS changes, and alpha testing will not really help us to reveal or understand those issues. While we discuss those issues in a separate thread, I would suggest that if alpha testing does not reveal any issues related to stability or maintenance of the server, then we learn nothing about the server changes, but that does not reduce the usefulness of the alpha testing in providing feedback about *other* changes.
Ivan, would you agree with that?
- Julian
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On 4/4/14, 10:17 AM, Bert Huijben wrote:
> And reasoning like this makes it even easier to ignore Windows...
> I can setup a clean Windows machine to build Subversion in a few hours max using VS 2005 up to 2013; probably less than 20 minutes unless you customized a lot of things on the machine...
Back when I had that experience, I followed this set of instructions:
http://blogs.collab.net/subversion/building-subversion-on-windows-a-walk-through
There are several typos and omissions in those instructions. If you have
better instructions by all means please share them.
> You decided to write your own scrips, so I think you know who to complain to that your scripts broke...
That was before I wrote the scripts. The scripts as far as I know still work
just fine for me. Though I haven't done a build in a while so I suppose
something may be busted.
I'd like to get back to them and update them to use the CMake builds for
APR/httpd since that should eliminate a lot of the crap I had to do in the
first place.
RE: 1.9.0-alpha2 up for testing/signing
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ben Reser [mailto:ben@reser.org]
> Sent: vrijdag 4 april 2014 18:45
> To: Ivan Zhakov
> Cc: Subversion Development
> Subject: Re: 1.9.0-alpha2 up for testing/signing
>
> On 4/4/14, 5:02 AM, Ivan Zhakov wrote:
> > And here is list of people voted for Unix release over the last year:
> > Branko
> > Philip
> > Stefan Fuhrmann
> > Julian
> > Stefan Sperling
> > C. Michael Pilato
> >
> > I had to vote for both Windows and Unix for 1.7.13 and 1.8.3, because
> > we cannot get Unix signatures within week for very critical security
> > release.
>
> That wasn't the point of me providing the list of people who had voted for
> Windows. My point was to show that out of the 5 people who have been
> voting
> for Windows releases, 2 voted, 1 couldn't vote due to not having a current
> setup (but raised no objections to the alpha), one hasn't said anything and
> you
> stayed silent about your objections until recently. That does not constitute a
> lack of interest in my opinion.
>
> However, to your point. The bar to getting someone to vote for Unix is much
> lower than for Windows. I voted for a Windows release back towards the
> end of
> 2012 because we couldn't find someone with a Windows setup. It took me
> the
> better part of a week to get a working setup. I still ended up with a setup
> that I couldn't use the next time. At least two of the people in the Unix list
> have worked on the Windows side in the past, but don't anymore. There's a
> reason for it.
And reasoning like this makes it even easier to ignore Windows...
I can setup a clean Windows machine to build Subversion in a few hours max using VS 2005 up to 2013; probably less than 20 minutes unless you customized a lot of things on the machine... You decided to write your own scrips, so I think you know who to complain to that your scripts broke...
Feel free to bring your VM to the Berlin Hackathon (or contact me) if you need a setup to build Subversion on Windows.
This reasoning is also what makes it hard for the TortoiseSVN developers to spend time on the Subversion side of things... They rather work around problems in TortoiseSVN than fixing things here, while we could really use their input... and in this case their testing effort.
The 1.9 code should make it *much easier* to test Subversion releases on Windows, because we can now link to binaries for all of our dependencies, and you can just put them in some directory with lib, bin and include subdirs. For 1.8 and earlier we expected source installs and nonstandard output directories in them all over the place. (One of the reasons TortoiseSVN ignores all our buildscripts and wrote their own)
I'm glad the Httpd and apr project finally moved away from only providing buildscripts for a 16 year old compiler chain. (Strange enough I read that some packagers are still getting this working for 1.9 even though we most likely broke some things for them... Probably by custom patches)
Introducing scons to the list of dependencies certainly doesn't help... You have to patch scons to support the recent compiler chains.
But I don't think this makes our users switch to a different platform... nor should they.
Bert
Re: 1.9.0-alpha2 up for testing/signing
Posted by Julian Foad <ju...@btopenworld.com>.
Stefan Sperling wrote:
> Ivan Zhakov wrote:
>> 3. I am not sure that the log adressing feature in the current
>> desing and implementaion is really valuable for users. On the other
>> side, we have the FSX format that is treated as experimental. The much
>> better way is to release log adressing feature in this new format and
>> see how it works in production (not during the alpha/beta testing).
>
> Like Julian, I don't see much of a difference between putting new
> changes into just FSX (leaving FSFS as it was in 1.8), and putting
> new changes into both FSX and FSFS. Users (and third-party vendors
> who offer SVN server implementations, in case this matters) will always
> have the option to keep using repositories in 1.8 format, even with a
> 1.9 server, if they feel the 1.9 FSFS format has not been proven stable.
> Remember that running 'svnadmin upgrade' is a manual step.
While I agree with that, I do also understand Ivan's concern about having a new format to maintain. That is a real difference between the two approaches.
>> As far as I can tell, the svn_fs_move() is never called (quite surprising).
>> Moreover, I'm unable to find any unit tests for svn_fs_move(). So it's not
>> worth to change the repository format for non-used feature.
>
> Agreed. But keep in mind that svn_fs_move() is marked experimental
> so we don't need to worry to much about the API.
>
> Though I'll note that svn_fs_path_change_kind_t has grown new
> move-related fields which aren't even marked as such:
>
> 1525419 stefan2 /** moved to this path in txn */
> 1525419 stefan2 svn_fs_path_change_move,
> 1525419 stefan2 /** path removed and replaced by moved path in txn */
> 1525419 stefan2 svn_fs_path_change_movereplace
>
> Those should be marked @since 1.9 at least. I've done so in r1585515.
> But I'm not sure if we can mark structure members as experimental,
> so this might need revisting...
>
> I'm most worried about the presence of a move-related option in 'svn log'
> since there doesn't seem to be any actual functionality behind it.
> I think this should be removed before release unless actual move-tracking
> features appear outside of the client's working copy. If it's needed for
> testing purposes, let's make it compile only with a special pre-processor
> flag or move development of the feature to a branch until it is complete.
+1 to all that about 'move'.
- Julian
Re: 1.9.0-alpha2 up for testing/signing
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Mon, Apr 7, 2014 at 6:28 PM, Stefan Sperling <st...@elego.de> wrote:
> > As far as I can tell, the svn_fs_move() is never called (quite
> surprising).
> > Moreover, I'm unable to find any unit tests for svn_fs_move(). So it's
> not
> > worth to change the repository format for non-used feature.
>
> Agreed. But keep in mind that svn_fs_move() is marked experimental
> so we don't need to worry to much about the API.
>
> Though I'll note that svn_fs_path_change_kind_t has grown new
> move-related fields which aren't even marked as such:
>
> 1525419 stefan2 /** moved to this path in txn */
> 1525419 stefan2 svn_fs_path_change_move,
> 1525419 stefan2 /** path removed and replaced by moved path in txn */
> 1525419 stefan2 svn_fs_path_change_movereplace
>
> Those should be marked @since 1.9 at least. I've done so in r1585515.
> But I'm not sure if we can mark structure members as experimental,
> so this might need revisting...
>
> I'm most worried about the presence of a move-related option in 'svn log'
> since there doesn't seem to be any actual functionality behind it.
> I think this should be removed before release unless actual move-tracking
> features appear outside of the client's working copy. If it's needed for
> testing purposes, let's make it compile only with a special pre-processor
> flag or move development of the feature to a branch until it is complete.
>
To shortcut this branch of the discussion:
I added the move API to give others *some* means
of experimenting with move-aware merges etc.
That did not happen but I'm fine with that since I hadn't
put much effort into the implementation (so, not much waste here).
My idea has always been to get rid of these parts
as part of the 1.9 API change cleanup if those additions
remained unused.
-- Stefan^2.
Re: 1.9.0-alpha2 up for testing/signing
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Apr 07, 2014 at 07:21:56PM +0400, Ivan Zhakov wrote:
> 3. I am not sure that the log adressing feature in the current
> desing and implementaion is really valuable for users. On the other
> side, we have the FSX format that is treated as experimental. The much
> better way is to release log adressing feature in this new format and
> see how it works in production (not during the alpha/beta testing).
Like Julian, I don't see much of a difference between putting new
changes into just FSX (leaving FSFS as it was in 1.8), and putting
new changes into both FSX and FSFS. Users (and third-party vendors
who offer SVN server implementations, in case this matters) will always
have the option to keep using repositories in 1.8 format, even with a
1.9 server, if they feel the 1.9 FSFS format has not been proven stable.
Remember that running 'svnadmin upgrade' is a manual step.
> As far as I can tell, the svn_fs_move() is never called (quite surprising).
> Moreover, I'm unable to find any unit tests for svn_fs_move(). So it's not
> worth to change the repository format for non-used feature.
Agreed. But keep in mind that svn_fs_move() is marked experimental
so we don't need to worry to much about the API.
Though I'll note that svn_fs_path_change_kind_t has grown new
move-related fields which aren't even marked as such:
1525419 stefan2 /** moved to this path in txn */
1525419 stefan2 svn_fs_path_change_move,
1525419 stefan2 /** path removed and replaced by moved path in txn */
1525419 stefan2 svn_fs_path_change_movereplace
Those should be marked @since 1.9 at least. I've done so in r1585515.
But I'm not sure if we can mark structure members as experimental,
so this might need revisting...
I'm most worried about the presence of a move-related option in 'svn log'
since there doesn't seem to be any actual functionality behind it.
I think this should be removed before release unless actual move-tracking
features appear outside of the client's working copy. If it's needed for
testing purposes, let's make it compile only with a special pre-processor
flag or move development of the feature to a branch until it is complete.
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 4 April 2014 20:45, Ben Reser <be...@reser.org> wrote:
>
> On 4/4/14, 5:02 AM, Ivan Zhakov wrote:
[...]
> > My opinion on Subversion 1.9.0 is the following: release Subversion
> > 1.9.0 ASAP without FSFS format change. We have many FSFS performance
> > improvements in trunk that doesn't require format change.
> >
> > I think that cost of maintaining disk format backward compatibility
> > and code destabilization doesn't worth the real benefits that users
> > get from fsfs7 performance improvements. On the other side: if
> > log-addressing and related stuff are so cool and rock-solid, users
> > always can switch to FSX and fully benefit from this new stuff.
>
> I guess all I can say is that I wish we'd had this discussion completely in
> November and resolved it. I'd like to see 1.9.0 in June (or earlier) but I
> don't know how realistic that is now that you want us to rip out significant
> amounts of work.
>
> Unfortunately though, none of this discussion helps with the issue at hand.
> What exactly do we need to do to make you happy with a 1.9.0-alpha release? Is
> there anything we can do? Is removing the format 7 code enough? Or if that
> was removed would you still be against it since you don't think it's useful?
>
> Bottom line, what do you want to do here?
Here are my thoughts.
I have the following concerns about the log addressing feature:
1. Data corruption is possible due to implementation bugs. We have had
a lot of bugs in revprop packing feature and I expect at least the
same amount of bugs in this feature. We are unable to identify these
bugs before the release due to obvious limitations of alpha and beta
testing. We haven't implemented the improved testing discussed in [1].
And overall quality of feature design and implementation seems far from
perfect.
2. Despite the possible bugs, maintenance burden will be increased
significatly. We are introducing additional FSFS format that
dramatically increase the code complexity. And we have a big code
duplication because this feature is actually copy-pasted from FSX
format.
3. I am not sure that the log adressing feature in the current
desing and implementaion is really valuable for users. On the other
side, we have the FSX format that is treated as experimental. The much
better way is to release log adressing feature in this new format and
see how it works in production (not during the alpha/beta testing).
These are my thoughts about the log adressing feature itself. Assuming
all of this I don't like the idea to release 1.9 alpha with this
feature. It will be easy to make an implicit decision for final
release "because we don't have any bug reports from alpha and beta
testers".
I propose to revert *all* the FSFS format changes (including the
svn_fs_move support) and then release the 1.9 alpha ASAP. I agree
that there are many other fixes and usefull improvements waiting for
release.
As far as I can tell, the svn_fs_move() is never called (quite surprising).
Moreover, I'm unable to find any unit tests for svn_fs_move(). So it's not
worth to change the repository format for non-used feature.
P.S. The whole situation reminds me the release of ra_serf in Subversion 1.7 :)
[1] http://mail-archives.apache.org/mod_mbox/subversion-dev/201311.mbox/%3CCABw-3YdV1YX0yU3cuWD8syPGpQxkLBUe=6h_bMkuBfA+vQf9XA@mail.gmail.com%3E
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On 4/4/14, 5:02 AM, Ivan Zhakov wrote:
> And here is list of people voted for Unix release over the last year:
> Branko
> Philip
> Stefan Fuhrmann
> Julian
> Stefan Sperling
> C. Michael Pilato
>
> I had to vote for both Windows and Unix for 1.7.13 and 1.8.3, because
> we cannot get Unix signatures within week for very critical security
> release.
That wasn't the point of me providing the list of people who had voted for
Windows. My point was to show that out of the 5 people who have been voting
for Windows releases, 2 voted, 1 couldn't vote due to not having a current
setup (but raised no objections to the alpha), one hasn't said anything and you
stayed silent about your objections until recently. That does not constitute a
lack of interest in my opinion.
However, to your point. The bar to getting someone to vote for Unix is much
lower than for Windows. I voted for a Windows release back towards the end of
2012 because we couldn't find someone with a Windows setup. It took me the
better part of a week to get a working setup. I still ended up with a setup
that I couldn't use the next time. At least two of the people in the Unix list
have worked on the Windows side in the past, but don't anymore. There's a
reason for it.
But none of that has anything to do with the issue at hand. Is there a lack of
interest in releasing an 1.9.0 alpha? The answer I pretty clearly no in my
opinion. I think the fact that nobody other than you is asserting that is
strong evidence. But given that we need 3 Windows votes and the only person
that seems to have a functional Windows setup who could vote right now seems to
be you.
Given our current policies that's essentially placing you in the position of
being able to veto moving forward with this.
> First time I raised my concerns about fsfs7 at SVN Hackathon 2013 in
> Berlin and decision
> was to implement *all* format changes in separate FS backend (FSX).
> FSX was implemented, but some of significant
> changes was copy-pasted to FSFS. Increasing code duplication significantly btw.
Right and Stefan Fuhrmann did implement all the changes on FSX and then
realized some of the changes could be made to FSFS. That seemed like a logical
thing to do to me.
> I've raised my concerns again on mailing list:
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201311.mbox/%3CCABw-3YdV1YX0yU3cuWD8syPGpQxkLBUe=6h_bMkuBfA+vQf9XA@mail.gmail.com%3E
>
> I think we shouldn't change FSFS disk format at least in Subversion
> 1.9.0, before we get some feedback about FSX ideas from the wild.
> Because we can fix almost any bug in future, but it's extremely costly
> to deal with on disk format mistakes.
>
> But log-addressing branch was pushed to trunk.
Okay I did forget about this conversation. But you seemed to be ok with
improved testing. Stefan agreed to implement the testing. The conversation
turned into a discussion about how effective that testing would be and then
died out. If you weren't satisfied with the discussion then why did you wait
until now to bring the topic up? Why have you waited a month to bring this up
with a pending 1.9.0-alpha2 waiting to be released? Why did you not bring this
up when 1.9.0-alpha1 was being prepared to release?
> My opinion on Subversion 1.9.0 is the following: release Subversion
> 1.9.0 ASAP without FSFS format change. We have many FSFS performance
> improvements in trunk that doesn't require format change.
>
> I think that cost of maintaining disk format backward compatibility
> and code destabilization doesn't worth the real benefits that users
> get from fsfs7 performance improvements. On the other side: if
> log-addressing and related stuff are so cool and rock-solid, users
> always can switch to FSX and fully benefit from this new stuff.
I guess all I can say is that I wish we'd had this discussion completely in
November and resolved it. I'd like to see 1.9.0 in June (or earlier) but I
don't know how realistic that is now that you want us to rip out significant
amounts of work.
Unfortunately though, none of this discussion helps with the issue at hand.
What exactly do we need to do to make you happy with a 1.9.0-alpha release? Is
there anything we can do? Is removing the format 7 code enough? Or if that
was removed would you still be against it since you don't think it's useful?
Bottom line, what do you want to do here?
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 2 April 2014 21:02, Ben Reser <be...@reser.org> wrote:
> On 4/2/14, 2:37 AM, Ivan Zhakov wrote:
>> I didn't vote for 1.9.0-alpha2 because I believe that current trunk
>> should not be released even with alpha label. So effectively my vote
>> was -0.5, but I decided didn't express my vote if will be 3+3 people
>> interesting in driving 1.9.0-alpha2. But reality shown that developers
>> are not interested so much in 1.9.0-alpha2.
>
> You're entitled to vote as you see fit. But I don't think the reality matches
> what you're saying. There are only a handful of people that ever vote for
> Windows releases.
>
> Specifically over the last year (probably longer but I got tired of looking)
> the following people have voted for a Windows release:
> Johan
> Bert
> Ivan
> Mark
> Paul
>
> Mark has said that his Windows setup has rotted. Paul hasn't said anything, so
> I can't make any assumptions about his motives. Johan and Bert voted +1.
>
> The lack of one vote hardly seems to indicate a disinterest from a plurality of
> developers. Obviously, you're not interested.
>
And here is list of people voted for Unix release over the last year:
Branko
Philip
Stefan Fuhrmann
Julian
Stefan Sperling
C. Michael Pilato
I had to vote for both Windows and Unix for 1.7.13 and 1.8.3, because
we cannot get Unix signatures within week for very critical security
release.
[...]
>> Even more I believe that fsfs7 stuff and log addressing stuff should
>> be reverted from trunk and such significant fsfs format changes should
>> be implemented in fsx to give users a choice: use stable and proven
>> format or something really new and never tested.
>
> I don't recall seeing objections to FSFS7 being on trunk and thus slated for
> 1.9.0 before this email. Seems rather odd to wait till now to object to them.
>
First time I raised my concerns about fsfs7 at SVN Hackathon 2013 in
Berlin and decision
was to implement *all* format changes in separate FS backend (FSX).
FSX was implemented, but some of significant
changes was copy-pasted to FSFS. Increasing code duplication significantly btw.
I've raised my concerns again on mailing list:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201311.mbox/%3CCABw-3YdV1YX0yU3cuWD8syPGpQxkLBUe=6h_bMkuBfA+vQf9XA@mail.gmail.com%3E
I think we shouldn't change FSFS disk format at least in Subversion
1.9.0, before we get some feedback about FSX ideas from the wild.
Because we can fix almost any bug in future, but it's extremely costly
to deal with on disk format mistakes.
But log-addressing branch was pushed to trunk.
> Even supposing we decided to remove it. There's nothing stopping us from doing
> this if we release 1.9.0-alpha2. We flat out don't promise compatibility
> between alpha/beta or even release candidate versions (we have even explicitly
> broken support for formats that have been in our release candidates in the past).
>
> So I'm really not understanding the objection here. If you really think FSFS7
> should be removed I think you should start a thread about that.
My opinion on Subversion 1.9.0 is the following: release Subversion
1.9.0 ASAP without FSFS format change. We have many FSFS performance
improvements in trunk that doesn't require format change.
I think that cost of maintaining disk format backward compatibility
and code destabilization doesn't worth the real benefits that users
get from fsfs7 performance improvements. On the other side: if
log-addressing and related stuff are so cool and rock-solid, users
always can switch to FSX and fully benefit from this new stuff.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On 4/2/14, 2:37 AM, Ivan Zhakov wrote:
> I didn't vote for 1.9.0-alpha2 because I believe that current trunk
> should not be released even with alpha label. So effectively my vote
> was -0.5, but I decided didn't express my vote if will be 3+3 people
> interesting in driving 1.9.0-alpha2. But reality shown that developers
> are not interested so much in 1.9.0-alpha2.
You're entitled to vote as you see fit. But I don't think the reality matches
what you're saying. There are only a handful of people that ever vote for
Windows releases.
Specifically over the last year (probably longer but I got tired of looking)
the following people have voted for a Windows release:
Johan
Bert
Ivan
Mark
Paul
Mark has said that his Windows setup has rotted. Paul hasn't said anything, so
I can't make any assumptions about his motives. Johan and Bert voted +1.
The lack of one vote hardly seems to indicate a disinterest from a plurality of
developers. Obviously, you're not interested.
> Changing release polices
> to overcome developers opinion is not good for community IMHO, but
> this is topic for another thread.
Considering that you didn't vote (for or against), I can't possibly be trying
to overcome opinion. Not one person has posted on the 1.9.0-alpha2 thread and
said we shouldn't release this. There have been some questions about if
certain breakages should stop it. In fact several developers have wondered why
it wasn't released already, Julian posted this to the thread, others did so in
private.
Now that you've actually raised an objection we can do something to try and
resolve it.
> The only big feature is fsfs7, but the past shows that users even
> didn't try Subversion on client before final release, so expecting
> that some sysadmin will try alpha on server doesn't make sense.
FSFS7 has nothing to do with the desire to release an alpha (in my opinion).
I'll point at the following changes:
svn auth
changes to the conflict resolver (some of which I'm -1 on)
kidney blame
Those changes probably could use feedback from end users about if they're
working right, if the UI has issues, etc...
I intend to include a statement asking for feedback on these changes with the
release. I'm sure other people can think of additional things they'd like to
ask for feedback for.
I know that WANdisco has had customers try pre-releases before in test
environments (server and client) to get feedback. I'm positive we'll have that
happen with this release.
> Even more I believe that fsfs7 stuff and log addressing stuff should
> be reverted from trunk and such significant fsfs format changes should
> be implemented in fsx to give users a choice: use stable and proven
> format or something really new and never tested.
I don't recall seeing objections to FSFS7 being on trunk and thus slated for
1.9.0 before this email. Seems rather odd to wait till now to object to them.
Even supposing we decided to remove it. There's nothing stopping us from doing
this if we release 1.9.0-alpha2. We flat out don't promise compatibility
between alpha/beta or even release candidate versions (we have even explicitly
broken support for formats that have been in our release candidates in the past).
So I'm really not understanding the objection here. If you really think FSFS7
should be removed I think you should start a thread about that.
RE: 1.9.0-alpha2 up for testing/signing
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
> Sent: woensdag 2 april 2014 11:37
> To: Ben Reser
> Cc: Subversion Development
> Subject: Re: 1.9.0-alpha2 up for testing/signing
>
> On 31 March 2014 21:25, Ben Reser <be...@reser.org> wrote:
> > On 3/4/14, 1:23 AM, Ben Reser wrote:
> >> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
> >> Please get the tarballs from
> >> https://dist.apache.org/repos/dist/dev/subversion
> >> and add your signatures there. There's no particular schedule to this it's
> >> ready when it's ready.
> >
> > All we need is one Windows vote (and have since the 19th). Can someone
> please
> > take a little bit of time to vote for Windows? Ivan or Mark you guys out
> there?
> >
>
> Hi Ben,
>
> I didn't vote for 1.9.0-alpha2 because I believe that current trunk
> should not be released even with alpha label. So effectively my vote
> was -0.5, but I decided didn't express my vote if will be 3+3 people
> interesting in driving 1.9.0-alpha2. But reality shown that developers
> are not interested so much in 1.9.0-alpha2. Changing release polices
> to overcome developers opinion is not good for community IMHO, but
> this is topic for another thread.
I agree with this reasoning. I think we should look at the alpha/beta release process and its potential audience instead of trying to release something that wasn't really tested.
I don't think we need the full test cycle of an actual release for an alpha, but just relaxing the rules to the point where we can release something is not the solution.
I would +1 something like at least X signatures (3, 4?), at least one Windows and one Unix vote... and something like the apache standard 72 hours (which we usually don’t have explicitly in our release cycle as we require more votes; which usually takes well over 72 hours).
We've had releases where we got either the *nix or the Windows votes in just a few hours after posting the binaries... (Which one mostly depended on the time of release (normal workweek vs long weekend)... I can't remember cases where we got both that fast)
But I'm wondering who we are releasing for if we can't even get our own developers to run a test cycle...
And do we really help them by releasing that had less testing from our side.
Should we really ask our users to test something, that we don't want to spend time on testing it ourselves?
Bert
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 2 April 2014 15:15, Julian Foad <ju...@btopenworld.com> wrote:
> Ivan Zhakov wrote:
>> I didn't vote for 1.9.0-alpha2 because I believe that current trunk
>> should not be released even with alpha label. [...]
>
> Hi, Ivan.
>
> I agree with some of what you say, but not all of it.
>
[...]
>> Even more I believe that fsfs7 stuff and log addressing stuff should
>> be reverted from trunk and such significant fsfs format changes should
>> be implemented in fsx to give users a choice: use stable and proven
>> format or something really new and never tested.
>
> I agree users must always have the option of a server that's "stable and proven". I take your concern seriously, but I look at it in a different way. You're proposing that users should have the following options:
>
> * experimental (1.9 FSX, lots of new stuff)
>
> * stable (1.9 FSFS, approximately same as 1.8, minor changes)
>
Yes, that what I'm proposing.
> Users already have a stable server: it's called 1.8, or 1.7 or whatever version has been around for long enough to satisfy their definition of "stable.
>
Users will consider Apache Subversion 1.9.1 as stable release too
(this is Apache branded release btw). And they will install it on
production servers. Also, Subversion 1.7.x will be deprecated in the
day of release Subversion 1.9.0.
> So another way of looking at the options that we can provide is:
>
> * experimental (1.9 FSX, lots of new stuff)
>
> * latest (1.9.0 FSFS, a balance between significant improvements and reasonable stability)
>
> * very stable (1.8.x series, for now, until a year or so has passed and the user then considers the 1.9.x series to be "very stable")
>
> It seems that we're currently looking at the user's options that second way. And that seems OK to me.
>
The real problem is disk format change and backward compatibility:
once Subversion 1.9.0 with fsfs7 will be released, we have to deal
with this format in the all future releases. Even if nobody will
upgrade to 1.9.0 and fsfs7.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: 1.9.0-alpha2 up for testing/signing
Posted by Andreas Stieger <an...@gmx.de>.
Hello,
On 02/04/14 17:06, Ben Reser wrote:
> On 4/2/14, 4:20 AM, Andreas Stieger wrote:
>> A good audience for these are distribution package maintainers and integrators. If you could bump all build dependencies to close to what you are planning (as in configure, INSTALL) that will be fab.
>
> We did indeed do this with 1.9.0-alpha2. It requires APR/APR-Util 1.3.x and
> Serf 1.3.4.
Yes, works fine with tests for my packages.
Andreas
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On 4/2/14, 4:20 AM, Andreas Stieger wrote:
> A good audience for these are distribution package maintainers and integrators. If you could bump all build dependencies to close to what you are planning (as in configure, INSTALL) that will be fab.
We did indeed do this with 1.9.0-alpha2. It requires APR/APR-Util 1.3.x and
Serf 1.3.4.
Re: 1.9.0-alpha2 up for testing/signing
Posted by Andreas Stieger <an...@gmx.de>.
A good audience for these are distribution package maintainers and integrators. If you could bump all build dependencies to close to what you are planning (as in configure, INSTALL) that will be fab.
Andreas
> On 2 Apr 2014, at 12:15, Julian Foad <ju...@btopenworld.com> wrote:
>
> Ivan Zhakov wrote:
>> I didn't vote for 1.9.0-alpha2 because I believe that current trunk
>> should not be released even with alpha label. [...]
>
> Hi, Ivan.
>
> I agree with some of what you say, but not all of it.
>
>> The only big feature is fsfs7, but the past shows that users even
>> didn't try Subversion on client before final release, so expecting
>> that some sysadmin will try alpha on server doesn't make sense.
>
> It's true that users don't test alpha releases very much. I believe you
> that sysadmins will test the server side even less. But I don't agree
> that "expecting that some sysadmin will try alpha on server doesn't make
> sense". If we don't release it, then nobody will try it; if we do
> release it, then some sysadmin *might* try it.
>
> There must be at least
> thousands of sysadmins running Subversion, some of whom will see the
> alpha release. It's not totally unreasonable that some might test it.
>
>> Even more I believe that fsfs7 stuff and log addressing stuff should
>> be reverted from trunk and such significant fsfs format changes should
>> be implemented in fsx to give users a choice: use stable and proven
>> format or something really new and never tested.
>
> I agree users must always have the option of a server that's "stable and proven". I take your concern seriously, but I look at it in a different way. You're proposing that users should have the following options:
>
> * experimental (1.9 FSX, lots of new stuff)
>
> * stable (1.9 FSFS, approximately same as 1.8, minor changes)
>
> Users already have a stable server: it's called 1.8, or 1.7 or whatever version has been around for long enough to satisfy their definition of "stable".
>
> So another way of looking at the options that we can provide is:
>
> * experimental (1.9 FSX, lots of new stuff)
>
> * latest (1.9.0 FSFS, a balance between significant improvements and reasonable stability)
>
> * very stable (1.8.x series, for now, until a year or so has passed and the user then considers the 1.9.x series to be "very stable")
>
> It seems that we're currently looking at the user's options that second way. And that seems OK to me.
>
> - Julian
>
Re: 1.9.0-alpha2 up for testing/signing
Posted by Julian Foad <ju...@btopenworld.com>.
Ivan Zhakov wrote:
> I didn't vote for 1.9.0-alpha2 because I believe that current trunk
> should not be released even with alpha label. [...]
Hi, Ivan.
I agree with some of what you say, but not all of it.
> The only big feature is fsfs7, but the past shows that users even
> didn't try Subversion on client before final release, so expecting
> that some sysadmin will try alpha on server doesn't make sense.
It's true that users don't test alpha releases very much. I believe you
that sysadmins will test the server side even less. But I don't agree
that "expecting that some sysadmin will try alpha on server doesn't make
sense". If we don't release it, then nobody will try it; if we do
release it, then some sysadmin *might* try it.
There must be at least
thousands of sysadmins running Subversion, some of whom will see the
alpha release. It's not totally unreasonable that some might test it.
> Even more I believe that fsfs7 stuff and log addressing stuff should
> be reverted from trunk and such significant fsfs format changes should
> be implemented in fsx to give users a choice: use stable and proven
> format or something really new and never tested.
I agree users must always have the option of a server that's "stable and proven". I take your concern seriously, but I look at it in a different way. You're proposing that users should have the following options:
* experimental (1.9 FSX, lots of new stuff)
* stable (1.9 FSFS, approximately same as 1.8, minor changes)
Users already have a stable server: it's called 1.8, or 1.7 or whatever version has been around for long enough to satisfy their definition of "stable".
So another way of looking at the options that we can provide is:
* experimental (1.9 FSX, lots of new stuff)
* latest (1.9.0 FSFS, a balance between significant improvements and reasonable stability)
* very stable (1.8.x series, for now, until a year or so has passed and the user then considers the 1.9.x series to be "very stable")
It seems that we're currently looking at the user's options that second way. And that seems OK to me.
- Julian
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 31 March 2014 21:25, Ben Reser <be...@reser.org> wrote:
> On 3/4/14, 1:23 AM, Ben Reser wrote:
>> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
>> Please get the tarballs from
>> https://dist.apache.org/repos/dist/dev/subversion
>> and add your signatures there. There's no particular schedule to this it's
>> ready when it's ready.
>
> All we need is one Windows vote (and have since the 19th). Can someone please
> take a little bit of time to vote for Windows? Ivan or Mark you guys out there?
>
Hi Ben,
I didn't vote for 1.9.0-alpha2 because I believe that current trunk
should not be released even with alpha label. So effectively my vote
was -0.5, but I decided didn't express my vote if will be 3+3 people
interesting in driving 1.9.0-alpha2. But reality shown that developers
are not interested so much in 1.9.0-alpha2. Changing release polices
to overcome developers opinion is not good for community IMHO, but
this is topic for another thread.
The only big feature is fsfs7, but the past shows that users even
didn't try Subversion on client before final release, so expecting
that some sysadmin will try alpha on server doesn't make sense.
Even more I believe that fsfs7 stuff and log addressing stuff should
be reverted from trunk and such significant fsfs format changes should
be implemented in fsx to give users a choice: use stable and proven
format or something really new and never tested.
--
Ivan Zhakov
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On 3/4/14, 1:23 AM, Ben Reser wrote:
> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. There's no particular schedule to this it's
> ready when it's ready.
All we need is one Windows vote (and have since the 19th). Can someone please
take a little bit of time to vote for Windows? Ivan or Mark you guys out there?
Re: 1.9.0-alpha2 up for testing/signing
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Mar 4, 2014 at 10:23 AM, Ben Reser <be...@reser.org> wrote:
> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. There's no particular schedule to this it's
> ready when it's ready.
>
Summary
-------
+1 to release
Platform
--------
Windows XP (32 bit) SP3
Microsoft Visual Studio 2010 SP1
Verified
--------
Signature and sha1 for subversion-1.9.0-alpha2.zip.
Contents of subversion-1.9.0-alpha2.zip are identical to tags/1.9.0-alpha2,
and to trunk@1573927 (except for expected differences in svn_version.h,
svnpubsub, svnwcsub and nominate.pl (symlinks vs. file contents)).
Tested
------
[ Release build ] x [ fsfs | fsx ] x [ file | svn | http ]
Results
-------
All tests pass, except:
- fs-x-pack-test.exe 3 (read from a packed FSX filesystem).
This issue is already fixed on trunk in r1575642.
Dependencies
------------
Httpd 2.4.4
Apr 1.4.6
Apr-Util 1.5.2
Apr-Iconv 1.2.1
OpenSSL 1.0.1e
Serf 1.3.4
SQLite 3.8.3.1
ZLib 1.2.8 (without assembly optimizations)
Signature
---------
subversion-1.9.0-alpha2.zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
iQIcBAABCgAGBQJTKc4hAAoJELWc5tYBDIqtQPoQAIOv6rEywQeV1VTPeJWIhWRN
ESIlWbz2dM2Pn3NO6FvjprY9E8PQL9E8fd2OMoZJ1rVGxrM8ZZ4/BSZx2ZXLPtkR
Yn4+v4q6X02lNpuVBk1kOWwGOkZm/2eil8CmDod79RPmYN5INnTazmSJt6ZrATAn
J7DtBWohRybMoYacMAEaUVBPHn7bh/eCqovRHiWtNWWJLZ7XYLX18wjZbP83M57N
mOdrUyx2lPeetTMmlEjZjvYePRSvPIDQ2Td997P4opr4kaOUZjD3vg9ik8hfwHPi
VK8Z4hdLFYACx/meBZLIXHE4B9tJC+jDrF7+OaFBf9MaLzu+v2hXIHRN+67dt4DT
n4AgPZw0OxB488n9MSwVLlns5Vd2ge0ToueYDHkAlz5VwNIFmXL10tbA3Df9OmGf
MTa5E3E522hMAPIIf2NsMVTclnZRIGmaNna844XnW++B4yHhBhxxNTPMJZTt4ynI
Xe6LuTzarG0LU3LuoeywRHe6wNg7rBkKJpnlFwn1CK6a2Q03ZnrUqYEtp+zKSRyJ
vDVfQ5X6Z9u3RIs+4HDZ7SxVLxP2YFNcmS2pbqzIaDGOMq/7lN5dnHJGvToHyyPx
MKERbOm89rSqZYkNgIY7JoTA1RDx+NV1Al0KEvc2R2Z7RPBDhXRiIzSSidfnpxlP
RYM6viWHXdIqSfjZLJ0Y
=JDYT
-----END PGP SIGNATURE-----
--
Johan
Re: 1.9.0-alpha2 up for testing/signing
Posted by Philip Martin <ph...@wandisco.com>.
Summary:
+1 to release
Platform:
Linux (Debian/wheezy) 64-bit
Tested:
(local, svn, svn/sasl, serf, serf/v1) x (fsfs, fsfs/pack/shard, bdb, fsx)
swig-pl, swig-py, swig-rb, ctypes-python
javahl x (fsfs, bdb, fsx)
Results:
getopt_tests.py 2 and 4 FAIL with KWallet enabled.
svnserve/SASL tests FAIL.
All other tests PASS.
Local dependencies:
apache2-threaded-dev : 2.2.22-13+deb7u1
libapr1-dev : 1.4.6-3+deb7u1
libaprutil1-dev : 1.4.1-3
libdb5.1-dev : 5.1.29-5
libsasl2-dev : 2.1.25.dfsg1-6+deb7u1
libsqlite3-dev : 3.7.17-1~bpo70+1
perl : 5.14.2-21+deb7u1
python2.7-dev : 2.7.3-6+deb7u2
ruby1.8-dev : 1.8.7.358-7.1+deb7u1
openjdk-7-jdk : 7u25-2.3.10-1~deb7u1
serf : 1.3.x@2313
subversion-1.9.0-alpha2.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAABCAAGBQJTKXW3AAoJEHbXiOHtGlmcC4AH/AlU8Qrd/bBeK1vaT48jq+VX
veN2AfdAGtW51G8xGXD9VfLEJkhlaegkVm3v4CF7sL9v6OnQ5OwHPaMWkYerzwHF
o3cIkbKe+FYNj6f8hGY4cLYqHYzy5Mc2Zr4ayEfwErdny9UzCBEFDWQ1uq7UjYXl
AYBf0SjYfjYGShbiAf9ZkFNzBd4fggM83XgoLdWh6am0zyhOAwkxsF/6C2YvSbr2
yVIQX9B5d6BWlfDeNKTY3ONd4WqTxJ+ieFvxrLQfJItCfh9FON0UqieOlUUAElYB
xHnVn1f3LwGfQ7Xe1+bw5ofAqgBCrsFmS2rv8MvFKzTUymgig5ORHm8Tnf3XezE=
=szUF
-----END PGP SIGNATURE-----
subversion-1.9.0-alpha2.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAABCAAGBQJTKXW3AAoJEHbXiOHtGlmcTMIH/1T/2RExwfCq7yZDnX+YVNC2
NHf68vj5SVqfVHvlbIuBnEwP/S+ebCk6CQu1WuUL/fW1XFlcc6spgp6Ao7x+d1yx
/mzX+0Xd3vImV+5ZmGoVrXMTMSIOSPDUX1vLd/4a0/KwTnyuVZRGNJumc7ER0CSd
3Ci9qq37eRTTIfm3n1ygEDEEzcUSVCBGK/+4HTPO0Z/QG456iPJ1BTRI0vWj6QzW
YA+ua+wBOwa/W1sJZdv+Uk91cB6B2EAh3kq4CPrAz/G3SrQbNjA8ZWRIYUWkMmbT
b6SUoyxAPxbZ6zaQRctG2WfibQ1KQw8hM4aM0umqtaAVPhi7eKFd7o52ZPsrjcE=
=rZpE
-----END PGP SIGNATURE-----
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: 1.9.0-alpha2 up for testing/signing
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Mar 4, 2014 at 10:23 AM, Ben Reser <be...@reser.org> wrote:
> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. There's no particular schedule to this it's
> ready when it's ready.
>
Summary:
+1 to release
Platform
Ubuntu 14.04 x64 (Jan 20 nightly), Linux 3.13.0-5-generic SMP
Standard dependencies:
APR 1.5.0
APR-Util 1.5.3
BDB 5.3.28
GCC 4.8.2
httpd 2.4.7, worker MPM
JUnit 4.11
libmagic 5.14
OpenJDK-7 7u51
OpenSSL 1.0.1f
Perl 5.18.2
Python 2.7.5+
Ruby 1.9.3
Swig 2.0.11
zlib 1.2.8
Manually installed and in-tree dependencies:
SQLite 3.8.2
Serf 1.3.4
ctypesgen svn-r151
Verified:
Tarball contents and signatures
(fsfs, bdb, fsx) x (local, svnserve, serf)
check-swig-py
check-swig-pl
check-swig-rb
check-javahl
check-ctypes-python
./get-deps.sh
Results:
All tests passed.
GPG Signatures committed to the dist/dev/subversion repository.
-- Stefan^2.
Re: 1.9.0-alpha2 up for testing/signing
Posted by Branko Čibej <br...@wandisco.com>.
Summary:
+1 to release
Platform
Mac OS X 10.9.1 Mavericks, build 13B42
Standard dependencies:
Apple clang(++) 5.0 (clang-500.2.79)/LLVM 3.3svn
APR 1.4.5
APR-Util 1.3.12
zlib 1.2.5
httpd 2.2.24
OpenSSL 0.9.8y
Python 2.7.5
Perl 5.16.2
Ruby 2.0.0p247
SQLite 3.7.13
Dependencies from homebrew:
SQLite 3.8.3
Serf 1.3.4
BDB 5.3.28
Swig 2.0.12
libmagic 5.16
Other dependencies:
Java 1.7.0_51-b13
JUnit 4.11
Verified:
Tarball contents and signatures
(fsfs, bdb) x (local, svnserve, dav) with SQLite 3.8.3
(fsfs) x (local) with SQLite 3.7.13
check-all-javahl
check-swig-py
check-swig-rb
check-swig-pl
New issues:
- 'make davautocheck' requires 'make mod_dontdothat'; the dependency
should be explicit in the makefile.
Known issues:
- C tests do not work with the --enable-optimize configure option.
GPG signatures committed to the dist/dev/subversion repository.
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: 1.9.0-alpha2 up for testing/signing
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Mar 19, 2014 at 12:27:34AM +0100, Stefan Fuhrmann wrote:
> On Wed, Mar 19, 2014 at 12:09 AM, Philip Martin
> > svnserve's SASL support is broken, see r1579080.
>
> It's a good to see that this alpha already uncovered
> a few feature breakages that we would usually not
> see before the first beta.
Or it could mean SASL support is lacking any test coverage whatsoever.
In an ideal universe this would have been found during normal trunk testing.
(Ditto for memcached support, BTW.)
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On 3/19/14, 3:50 AM, Julian Foad wrote:
> The point of an alpha is it's up for testing despite having *known and unknown* bugs. It would be absurd to wait for a non-show-stopper bug to be fixed.
Agreed, no reason to hold up for the SASL issue. The https certificate thing
was a different matter.
> Come to that, it seems over-the-top that we are waiting for as much developer sign-off on this *alpha* release as we require for a production-quality release. It's been validated by at least one Unix system and at least one Windows dev; that's enough for me. Just release it and get the wider testing under way!
It's still a release even if it's an alpha. Subversion's policy is 3 for
Windows and 3 for Unix. ASF policy is 3 votes. So we could reduce the
requirement to just 3 votes. However, if we really wanted this out there now,
without any change in policy, we could do it quickly.
Nobody is obligated to do any specific testing in order to grant their vote.
I'd say that the minimum effort is to check that the code matches the source
branch revision it's supposed to other than the expected differences.
Some people are not really going to be comfortable doing just the minimum. But
I don't think the vote policy is terribly onerous. The only thing really
holding us back here is individual developers decisions to not vote.
What those reasons are for not voting, I can't say but I suspect they fall into
these categories:
* Environmental/Dependency issues (Windows is particularly prone to this
because it can be fussy trying to get the setup done).
* Someone else will do it.
* Too busy.
Re: 1.9.0-alpha2 up for testing/signing
Posted by Julian Foad <ju...@btopenworld.com>.
Stefan Fuhrmann wrote:
> Philip Martin wrote:
>> svnserve's SASL support is broken, see r1579080.
>
> It's a good to see that this alpha already uncovered
>
> a few feature breakages that we would usually not
> see before the first beta.
>
>> How important is working SASL support?
>
> Hm. I don't think this bug interferes with people's ability
> to test the new bits that we like to get feedback on.
+1.
The point of an alpha is it's up for testing despite having *known and unknown* bugs. It would be absurd to wait for a non-show-stopper bug to be fixed.
Come to that, it seems over-the-top that we are waiting for as much developer sign-off on this *alpha* release as we require for a production-quality release. It's been validated by at least one Unix system and at least one Windows dev; that's enough for me. Just release it and get the wider testing under way!
- Julian
Re: 1.9.0-alpha2 up for testing/signing
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Mar 19, 2014 at 12:09 AM, Philip Martin
<ph...@wandisco.com>wrote:
> Ben Reser <be...@reser.org> writes:
>
> > On 3/4/14, 1:23 AM, Ben Reser wrote:
> >> The 1.9.0-alpha2 release artifacts are now available for
> testing/signing.
> >> Please get the tarballs from
> >> https://dist.apache.org/repos/dist/dev/subversion
> >> and add your signatures there. There's no particular schedule to this
> it's
> >> ready when it's ready.
> >
> > Vote count stands at:
> > *nix: 2
> > Windows: 1
> >
> > There hasn't been a vote in a while. Please test and vote if you get a
> chance,
> > there's no rush but it'd be nice to get this out.
>
> svnserve's SASL support is broken, see r1579080.
It's a good to see that this alpha already uncovered
a few feature breakages that we would usually not
see before the first beta.
> How important is
> working SASL support?
>
Hm. I don't think this bug interferes with people's ability
to test the new bits that we like to get feedback on.
-- Stefan^2.
Re: 1.9.0-alpha2 up for testing/signing
Posted by Philip Martin <ph...@wandisco.com>.
Ben Reser <be...@reser.org> writes:
> On 3/4/14, 1:23 AM, Ben Reser wrote:
>> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
>> Please get the tarballs from
>> https://dist.apache.org/repos/dist/dev/subversion
>> and add your signatures there. There's no particular schedule to this it's
>> ready when it's ready.
>
> Vote count stands at:
> *nix: 2
> Windows: 1
>
> There hasn't been a vote in a while. Please test and vote if you get a chance,
> there's no rush but it'd be nice to get this out.
svnserve's SASL support is broken, see r1579080. How important is
working SASL support?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: 1.9.0-alpha2 up for testing/signing
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Mar 18, 2014 at 9:42 PM, Ben Reser <be...@reser.org> wrote:
> On 3/18/14, 9:52 AM, Johan Corveleyn wrote:
>> I get one failure when testing with FSX:
>>
>> [[[
>> svn_tests: E160057: Node revision index 26 exceeds container size 26
>> FAIL: fs-x-pack-test.exe 3: read from a packed FSX filesystem
>> ]]]
>>
>> Anyone else seeing this?
>
> Look the same as this to me:
> https://mail-archives.apache.org/mod_mbox/subversion-dev/201403.mbox/%3C531A45B7.9010304%40reser.org%3E
>
> Can you see if r1575642 resolves this for you?
Thanks. That fixes it.
> I'm not overly concerned with FSX issues since it's entirely experimental at
> this point.
>
Indeed, I wasn't intending to hold up my signature because of that.
Just didn't get around to wrapping it up. Coming up later today ...
--
Johan
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On 3/18/14, 9:52 AM, Johan Corveleyn wrote:
> I get one failure when testing with FSX:
>
> [[[
> svn_tests: E160057: Node revision index 26 exceeds container size 26
> FAIL: fs-x-pack-test.exe 3: read from a packed FSX filesystem
> ]]]
>
> Anyone else seeing this?
Look the same as this to me:
https://mail-archives.apache.org/mod_mbox/subversion-dev/201403.mbox/%3C531A45B7.9010304%40reser.org%3E
Can you see if r1575642 resolves this for you?
I'm not overly concerned with FSX issues since it's entirely experimental at
this point.
Re: 1.9.0-alpha2 up for testing/signing
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Mar 16, 2014 at 11:23 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Fri, Mar 14, 2014 at 4:46 PM, Ben Reser <be...@reser.org> wrote:
>> On 3/4/14, 1:23 AM, Ben Reser wrote:
>>> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
>>> Please get the tarballs from
>>> https://dist.apache.org/repos/dist/dev/subversion
>>> and add your signatures there. There's no particular schedule to this it's
>>> ready when it's ready.
>>
>> Vote count stands at:
>> *nix: 2
>> Windows: 1
>>
>> There hasn't been a vote in a while. Please test and vote if you get a chance,
>> there's no rush but it'd be nice to get this out.
>>
>
> I'll probably be able to test / vote on Windows sometime during the coming week.
I get one failure when testing with FSX:
[[[
svn_tests: E160057: Node revision index 26 exceeds container size 26
FAIL: fs-x-pack-test.exe 3: read from a packed FSX filesystem
]]]
Anyone else seeing this?
--
Johan
Re: 1.9.0-alpha2 up for testing/signing
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Mar 14, 2014 at 4:46 PM, Ben Reser <be...@reser.org> wrote:
> On 3/4/14, 1:23 AM, Ben Reser wrote:
>> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
>> Please get the tarballs from
>> https://dist.apache.org/repos/dist/dev/subversion
>> and add your signatures there. There's no particular schedule to this it's
>> ready when it's ready.
>
> Vote count stands at:
> *nix: 2
> Windows: 1
>
> There hasn't been a vote in a while. Please test and vote if you get a chance,
> there's no rush but it'd be nice to get this out.
>
I'll probably be able to test / vote on Windows sometime during the coming week.
--
Johan
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On 3/4/14, 1:23 AM, Ben Reser wrote:
> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. There's no particular schedule to this it's
> ready when it's ready.
Vote count stands at:
*nix: 2
Windows: 1
There hasn't been a vote in a while. Please test and vote if you get a chance,
there's no rush but it'd be nice to get this out.
Re: Remove tools/buildbot from tarballs?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Mar 19, 2014 at 12:51:40AM +0000, Philip Martin wrote:
> Ben Reser <be...@reser.org> writes:
>
> > The 1.9.0-alpha2 release artifacts are now available for testing/signing.
>
> Is it worth stripping tools/buildbot from the tarball?
+1 I don't think anyone compiling from a tarball needs these files.
Index: tools/dist/dist.sh
===================================================================
--- tools/dist/dist.sh (revision 1578108)
+++ tools/dist/dist.sh (working copy)
@@ -228,6 +228,12 @@ ver_major=`echo $VERSION | cut -d '.' -f 1`
ver_minor=`echo $VERSION | cut -d '.' -f 2`
ver_patch=`echo $VERSION | cut -d '.' -f 3`
+# Remove tools/dev/buildbot from our distribution tarball.
+# End users cannot really do anything with these files.
+if [ "$ver_major" -eq "1" -a "$ver_minor" -ge "9" ]; then
+ rm -rf "$DISTPATH/tools/buildbot"
+fi
+
# Remove contrib/ from our distribution tarball. Some of it is of
# unknown license, and usefulness.
# (See http://svn.haxx.se/dev/archive-2009-04/0166.shtml for discussion.)
Re: Remove tools/buildbot from tarballs?
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Is it worth stripping tools/buildbot from the tarball? The files are no
> real use in the tarball but they are not very big either, perhaps 12KB
> in the tarball and 248KB unpacked.
It seems a bit ugly to be selectively including and excluding parts of the 'tools' directory.
This idea suggests to me that 'tools/' is not the right place for the buildbot config. Perhaps they should go in a higher-level directory. Even outside the trunk/branches/tags directories, since the complete set of buildbot configs should not be specific to one branch of the source code but rather should be a single set of configurations that handle all currently interesting trunks/tags/branches.
(The same argument may apply to any scripts we have for building / releasing / packaging / testing / signing, that are used for multiple branches.)
- Julian
Remove tools/buildbot from tarballs?
Posted by Philip Martin <ph...@wandisco.com>.
Ben Reser <be...@reser.org> writes:
> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
Is it worth stripping tools/buildbot from the tarball? The files are no
real use in the tarball but they are not very big either, perhaps 12KB
in the tarball and 248KB unpacked.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: 1.9.0-alpha2 up for testing/signing
Posted by Ben Reser <be...@reser.org>.
On 3/4/14, 2:23 AM, Ben Reser wrote:
> The 1.9.0-alpha2 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. There's no particular schedule to this it's
> ready when it's ready.
So it's looking like the vote to change the policy for voting for alpha/beta
release is going to pass (it will have been 72 hours since I started the vote
tomorrow morning).
If for any reason the changing in the policy impacts any votes that have been
cast in this thread please speak up as soon as possible. I'm going to assume
that nobody is changing their votes unless they say otherwise.
My plan is to stage the release Thursday after the vote passes. But I will
delay releasing until Monday morning for a couple reason. First I'll be
traveling on Friday when I could do the release and I don't really want to
juggle a release while making my flight. Second, Friday releases are less than
ideal because by the time I'm doing them (US time) then Europe is already
heading home for the last day of the week. So I'd rather delay till Monday.
This has the added benefit of giving everyone a few days to respond if they object.
Summary: 1.9.0-alpha2 staging morning of Thursday April 10th (US Time).
Release announcement 9am US/PDT (-0700) Monday April 14th.