Re: Intentions for 1.11 release timing

[Julian Foad]

> Julian Foad wrote:
> > > Committed to http://subversion-staging.apache.org/roadmap.html in 
> > > http://svn.apache.org/r1835861 [...]
> > > 
> > > OK?
> > 
> > My thoughts:
> > 
> > * should say patch releases are not time-based but ad-hoc (Marcin K. 
> > just asked about this on IRC)
> > 
> > * should say we'll extend the support period if the gap between releases 
> > is longer than planned
> > 
> > * should say why we are changing to faster releases (to get features out 
> > sooner, to make feature development more interesting/rewarding/quicker)
> > 
> > When we're happy with it, I'll publish it (and do another short news 
> > item saying we changed it).

Having heard no further feedback, I am assuming consent.

I have applied the changes I mentioned above in r1837961, r1837962, r1837964 
and merged it all to 'publish' in r1837965.

-- 
- Julian

Re: No longer supply SHA1 checksums for new releases

[Julian Foad]

Daniel Shahaf wrote:
> I don't know if the distinction between "the Subversion developers
> assessed SHA-1 as too weak" and "ASF Infra assessed SHA-1 as too weak"
> is important enough to be drawn in the release notes.  The technical argument
> and end result are the same regardless of who made the decision.
> 
> HACKING could certainly mention this detail, though.

OK, your call, it was just a suggestion based on my preference for pointing to 
source material.

-- 
- Julian

Re: No longer supply SHA1 checksums for new releases

[Daniel Shahaf]

Julian Foad wrote on Mon, 13 Aug 2018 15:28 +0100:
> Daniel Shahaf wrote:
> > Thank you!  Documented in the 1.11 release notes in r1837957.
> 
> Thanks. Maybe change the rationale:
> 
> - We consider the SHA-1 cryptographic hash function too weak for our needs.
> + This change follows the ASF release policy.
> 
> ?

The reason ASF's policy recommends against sha1 is because it is "too
weak", as the page currently states.

I don't know if the distinction between "the Subversion developers
assessed SHA-1 as too weak" and "ASF Infra assessed SHA-1 as too weak"
is important enough to be drawn in the release notes.  The technical argument
and end result are the same regardless of who made the decision.

HACKING could certainly mention this detail, though.

Cheers,

Daniel

Re: No longer supply SHA1 checksums for new releases

[Julian Foad]

Daniel Shahaf wrote:
> Thank you!  Documented in the 1.11 release notes in r1837957.

Thanks. Maybe change the rationale:

- We consider the SHA-1 cryptographic hash function too weak for our needs.
+ This change follows the ASF release policy.

?
-- 
- Julian

Re: No longer supply SHA1 checksums for new releases

[Daniel Shahaf]

Julian Foad wrote on Mon, 13 Aug 2018 14:33 +0100:
> Daniel Shahaf wrote:
> > Daniel Shahaf wrote:
> > > Correct me if I'm wrong, but wouldn't reverting the first hunk of
> > > r1837939 and making it conditional upon [...]
> > 
> > 'args.version < Version("1.11.0-alpha1")'.
> 
> Thanks, Daniel. Tested and committed in http://svn.apache.org/r1837946

Thank you!  Documented in the 1.11 release notes in r1837957.

Re: svn commit: r1837321 - in /subversion/site/publish: docs/release-notes/1.10.html faq.html

[Julian Foad]

Daniel Shahaf wrote:
> Is anyone working on a patch to revise the release notes and FAQ along 
> these lines?

It would be fine to add your comments as comments. This does not need to be 
written like a manual, it is only some notes to try to help a user who runs 
into such a problem.

-- 
- Julian

Re: Re-drawing a road map: what to work on next, after 1.11?

[Julian Foad]

Julian Foad wrote:
> https://cwiki.apache.org/confluence/display/SVN/Road+Map
> 
> Can you all improve on that organization and add items, please?

I don't mean to sound pushy. Go ahead there if appropriate. Or discuss here. 
I'm happy to move items from email to the wiki if that helps.

-- 
- Julian

Re: No longer supply SHA1 checksums for new releases

[Julian Foad]

Daniel Shahaf wrote:
> Daniel Shahaf wrote:
> > Correct me if I'm wrong, but wouldn't reverting the first hunk of
> > r1837939 and making it conditional upon [...]
> 
> 'args.version < Version("1.11.0-alpha1")'.

Thanks, Daniel. Tested and committed in http://svn.apache.org/r1837946

-- 
- Julian

Re-drawing a road map: what to work on next, after 1.11?

[Julian Foad]

With a feature freeze beginning for 1.11, what do we want to do next?

We have suffered before from writing a load of wish list items with no 
indication whether they are really going to happen. Let's try to avoid that, 
and give realistic expectations to any reader.

It's probably best to write on a Wiki page. How to organize the categories?

* Developments that are really going ahead, that someone is leading;
* Developments that are important, that we really must do some time soonish, 
but for which we don't have the resources;
* Developments that are easy, that someone could do quickly if they want to.

Here's such a skeleton page: 
https://cwiki.apache.org/confluence/display/SVN/Road+Map

Can you all improve on that organization and add items, please?

-- 
- Julian

Re: "Permission denied" committing to sourceforge

[Daniel Shahaf]

Thomas Singer wrote on Mon, 13 Aug 2018 14:56 +0200:
> The user ensured to have used the same working copy. Is there some way 
> to debug it to find out why his SVN binary behaves different then ours? 
> Thanks in advance.

The simplest explanation is that it's a cygwin svn.exe v. a windows
svn.exe.  Those two would use different config dirs and hence different
credential caches.  You can use the 'svn auth' command to list the
saved credentials.

Re: No longer supply SHA1 checksums for new releases

[Daniel Shahaf]

Daniel Shahaf wrote on Mon, 13 Aug 2018 12:54 +:
> Correct me if I'm wrong, but wouldn't reverting the first hunk of
> r1837939 and making it conditional upon a 'version < Version(1,11,0)'

Sorry, that would be a RuntimeError.  The condition should be
'args.version < Version("1.11.0-alpha1")'.

> check be all we need to do to have release.py generate *.sha1 files for
> 1.10 and earlier only, but not add sha1 info to emails and download
> pages for any future release?  See attachment.

Re: AW: AW: "Permission denied" committing to sourceforge

[Thomas Singer]

On 2018-08-11 13:18, Branko Čibej wrote:

On 10.08.2018 16:06, Markus Schaber wrote:

Hi, Brane,

Von: Branko Čibej 

On 10.08.2018 14:30, Branko Čibej wrote:

On 10.08.2018 13:37, Markus Schaber wrote:

Von: Thomas Singer  On 2018-08-10 9:52,
Branko Čibej wrote:

On 10.08.2018 09:44, Stefan Sperling wrote:

On Fri, Aug 10, 2018 at 08:44:08AM +0200, Thomas Singer wrote:

When trying to commit to a sourceforge repository using a
self-compiled SVN binary, I'm getting following error:

D:\temp\irrlicht>svn.exe commit --username HinzKunz -m "a message"
Authentication realm:  SourceForge
User Password for 'HinzKunz': 
svn: E13: Commit failed (details below):
svn: E13: Can't create directory
'/svn/p/irrlicht/code/db/transactions/5634-1.txn': Permission
denied

Could this mean that we have built the SVN binary incomplete
(missing a part that is required for committing to sourceforge but
not other SVN repositories)? How can I get some helpful logging? Thanks in 
advance.


I believe you'll need to ask sourceforge about this. This looks
like a server-side problem and there is nothing an SVN client could do about it.

More specifically, it looks like filesystem permissions on the
repository storage are incorrect.

Thanks. That's what I thought initially, too, simply guessing from the error 
message. But the user who reported the problem writes that with his default SVN 
binaries the commit succeeded for him, and I'm not sure that's it's not a 
problem with our SVN binaries.

Is it possible that there's a difference in protocols?

If the one user uses https://, and the other uses svn:// or svn+ssh:// 
protocols, the server side has different software, probably running under 
different user account and permissions.

Of course, but it's still the server administrators responsibility to
make things work (i.e., set process/file ownership and permissions
correctly) if they support both http:// and svn:// protocols. Nothing
on the client side can affect that.

Agreed.


By the way: the protocol used is determined by the working copy, not by the 
client software; unless some info is missing from your report, both clients are 
using the same protocol.

Hmm, yes it's in the working copy. But that "missing information" was what I 
suspected. One part (which is not necessarily covered by working copy) could be user 
name, especially with svn+ssh:// - on the other hand, the pasted example uses https:// 
URLs. So I withdraw everything. :-)


Actually, the username could be different for https:// as well. In
theory, differently compiled clients could use different credentials caches.

-- Brane


The user ensured to have used the same working copy. Is there some way 
to debug it to find out why his SVN binary behaves different then ours? 
Thanks in advance.


-- Tom

Re: No longer supply SHA1 checksums for new releases

[Daniel Shahaf]

Julian Foad wrote on Mon, 13 Aug 2018 13:32 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote on Mon, 13 Aug 2018 12:59 +0100:
> > > * stop producing *.sha1 files and stop listing SHA1 on the 'downloads' 
> > > page
> > > 
> > >   -- http://svn.apache.org/r1837939
> > 
> > I was under the impression that we should keep producing *.sha1 files
> > for 1.9 and 1.10 releases, for compatibility reasons.  The "SHOULD NOT"
> > language in the policy was specifically intended to allow this sort of
> > compatibility.
> > 
> > To be clear, I'm suggesting that we only drop sha1 checksums for 
> > 1.11.0-alpha1
> > and newer.  WDYT?
> 
> Sounds good. I suggest for the time being we should achieve this by 
> using a pre-r1837939 revision of trunk/tools/dist/ when running 
> 'release.py' for 1.10 and older patch releases, and manually tweak the 
> result as necessary, such as omitting the SHA1 column from the 
> 'downloads' page.
> 
> If any future changes to release.py begin to make this approach 
> impractical we can revisit it then.

I would say that _anything_ that requires the RM to remember to make a
manual step that isn't in the "Rolling a release" runbook is
impractical.  In particular, requiring the RM to run an old version has
two problems:

1. The RM is liable to use the HEAD version as per normal procedure.

2. If patches that are added to HEAD in the future will be required for
   rolling 1.10 versions too, the RM will have to do merges and possibly
   conflict resolution before being able to roll a release.

We can solve #1 by adding a fast-exit path, e.g., something along the lines of 
---
.
if version < Version(1,11,0):
sys.exit('Revert r1837939 locally and remove this if block before 
rolling pre-1.11 versions')
.
--- but that wouldn't solve #2.

Correct me if I'm wrong, but wouldn't reverting the first hunk of
r1837939 and making it conditional upon a 'version < Version(1,11,0)'
check be all we need to do to have release.py generate *.sha1 files for
1.10 and earlier only, but not add sha1 info to emails and download
pages for any future release?  See attachment.

Cheers,

Daniel
Index: release.py
===
--- release.py	(revision 1837940)
+++ release.py	(working copy)
@@ -713,6 +713,13 @@ def roll_tarballs(args):
 filepath = os.path.join(get_tempdir(args.base_dir), filename)
 shutil.move(filepath, get_deploydir(args.base_dir))
 filepath = os.path.join(get_deploydir(args.base_dir), filename)
+if args.version < Version(1, 11, 0):
+# 1.10 and earlier generate *.sha1 files for compatibility reasons.
+# They are deprecated, however, so we don't publicly link them in
+# the announcements any more.
+m = hashlib.sha1()
+m.update(open(filepath, 'r').read())
+open(filepath + '.sha1', 'w').write(m.hexdigest())
 m = hashlib.sha512()
 m.update(open(filepath, 'r').read())
 open(filepath + '.sha512', 'w').write(m.hexdigest())

Re: [PATCH] fix repos-to-wc copy dst parents creation

[Julian Foad]

> Nikita Slyusarev wrote on 04 Aug 2018:
> > For everyone's sanity I'd better not only bump the thread, but also 
> > resend the patch and the log message I had prepared back then.

Daniel Shahaf wrote:
> Filed SVN-4768.  If anyone could review the patch, that'd be great;

Thank you Nikita for continuing to push this. We are grateful for your 
contribution, and only limited by having very few active contributors. I have 
your email marked for attention in my mail box. I will make sure I get to it 
soon-ish if nobody else does.

-- 
- Julian

Feature freeze for 1.11

[Julian Foad]

We plan to release 1.11 in October, let's say mid-October, so we should branch 
and feature-freeze in mid-August, which is just about now.

AFAIK the only significant new work is the experimental 'checkpointing' 
extension to shelving.

  -> I will wrap that up by finishing or disabling any unfinished parts. 
'shelf-diff' needs attention, in particular.

The new simpler release schedule description that we agreed on is still in 
'staging'.

  -> I will publish it.

Is anyone working on or planning any other enhancements, features, or anything 
that needs to be 'frozen'?

Separately, we should discuss what to work on next. I will start a separate 
thread for that.

Any concerns or thoughts?

-- 
- Julian

Re: No longer supply SHA1 checksums for new releases

[Julian Foad]

Daniel Shahaf wrote:
> Julian Foad wrote on Mon, 13 Aug 2018 12:59 +0100:
> > * stop producing *.sha1 files and stop listing SHA1 on the 'downloads' page
> > 
> >   -- http://svn.apache.org/r1837939
> 
> I was under the impression that we should keep producing *.sha1 files
> for 1.9 and 1.10 releases, for compatibility reasons.  The "SHOULD NOT"
> language in the policy was specifically intended to allow this sort of
> compatibility.
> 
> To be clear, I'm suggesting that we only drop sha1 checksums for 1.11.0-alpha1
> and newer.  WDYT?

Sounds good. I suggest for the time being we should achieve this by using a 
pre-r1837939 revision of trunk/tools/dist/ when running 'release.py' for 1.10 
and older patch releases, and manually tweak the result as necessary, such as 
omitting the SHA1 column from the 'downloads' page.

If any future changes to release.py begin to make this approach impractical we 
can revisit it then.

- Julian

Re: No longer supply SHA1 checksums for new releases

[Daniel Shahaf]

Julian Foad wrote on Mon, 13 Aug 2018 12:59 +0100:
> We "SHOULD NOT" any longer publish SHA1 checksums for new releases, according 
> to
> https://www.apache.org/dev/release-distribution#sigs-and-sums
> 
> So I have done this:
> 
> * remove references to SHA1 from the documentation
> 
>   -- http://svn.apache.org/r1837935
> 

+1

> * stop producing *.sha1 files and stop listing SHA1 on the 'downloads' page
> 
>   -- http://svn.apache.org/r1837939
> 

I was under the impression that we should keep producing *.sha1 files
for 1.9 and 1.10 releases, for compatibility reasons.  The "SHOULD NOT"
language in the policy was specifically intended to allow this sort of
compatibility.

To be clear, I'm suggesting that we only drop sha1 checksums for 1.11.0-alpha1
and newer.  WDYT?

> * remove SHA1 listings from the 'downloads' web page for current releases
> 
>   -- http://svn.apache.org/r1837938
> 

+1

> Thanks to Paul Hammant for mentioning this policy to me.

Thank you for doing the legwork.

Cheers,

Daniel

No longer supply SHA1 checksums for new releases

[Julian Foad]

We "SHOULD NOT" any longer publish SHA1 checksums for new releases, according to
https://www.apache.org/dev/release-distribution#sigs-and-sums

So I have done this:

* remove references to SHA1 from the documentation

  -- http://svn.apache.org/r1837935

* stop producing *.sha1 files and stop listing SHA1 on the 'downloads' page

  -- http://svn.apache.org/r1837939

* remove SHA1 listings from the 'downloads' web page for current releases

  -- http://svn.apache.org/r1837938

Thanks to Paul Hammant for mentioning this policy to me.

-- 
- Julian

Re: [PATCH] fix repos-to-wc copy dst parents creation

[Daniel Shahaf]

Nikita Slyusarev wrote on Sat, 04 Aug 2018 17:47 +0300:
> For everyone's sanity I'd better not only bump the thread, but also 
> resend the patch and the log message I had prepared back then.
> 

Filed SVN-4768.  If anyone could review the patch, that'd be great;
it's a one-liner fix with a test...

> [[[
> Correctly handle existing parent directories when performing repos-to-wc copy.
> 
> * subversion/libsvn_client/copy.c
>   (repos_to_wc_copy): If add_parents flag is set and destination parent
>   directory exists, but is unversioned, put it under version control. Wc-to-wc
>   copy behaves this way, and so should repos-to-wc copy do.
> 
> * subversion/tests/cmdline/copy_tests.py
>   (copy_make_parents_repo_wc,
>    copy_make_parents_wc_wc): Check behaviour with dst directory pre-creation
>   for both repo-to-wc and wc-to-wc test cases.
> ]]]
> 
> Email had 1 attachment:
> + subversion-libsvn_client-copy-with_tests.patch
>   6k (text/x-diff)