for those subcommands. I agree that it shouldn't be added as a global
option.
There's quite a bit of release.py that should be reviewed and cleaned up
> (e.g., I don't think we use the buildbot update command at all).
>
I'll start by taking a look at all the places wher
On 25. 9. 24 08:20, Daniel Sahlberg wrote:
Hi,
I'm trying to read up on release.py (planning to make one of the
upcoming releases - no promises I'll be done in time for 1.14.4 though).
There are quite a few cases where there is a dry_run parameter, for
example in run_command:
Hi,
I'm trying to read up on release.py (planning to make one of the upcoming
releases - no promises I'll be done in time for 1.14.4 though).
There are quite a few cases where there is a dry_run parameter, for example
in run_command:
[[[
def run_command(cmd, verbose=True, hide_st
dsahlb...@apache.org wrote on Thu, Jul 14, 2022 at 19:40:58 -:
> Author: dsahlberg
> Date: Thu Jul 14 19:40:57 2022
> New Revision: 1902722
>
> URL: http://svn.apache.org/viewvc?rev=1902722&view=rev
> Log:
> Follow-up to r1902582: Improvements to the release.py
t;> > +++ subversion/trunk/tools/dist/release.py Fri Jul 8 20:47:42 2022
>> > @@ -980,7 +979,12 @@ def roll_tarballs(args):
>> > # from a committer's LDAP profile down the road)
>> > basename = 'subversion-%s.KEYS' % (str(args.versi
Thanks for the review. I've committed a few changes as r1902722. More below.
Den ons 13 juli 2022 kl 15:57 skrev Daniel Shahaf :
> dsahlb...@apache.org wrote on Fri, Jul 08, 2022 at 20:47:42 -:
> > +++ subversion/trunk/tools/dist/release.py Fri Jul 8 20:47:42 2022
> &g
t; Log:
> > ASF no longer provide a aggregated KEYS file, so we need to construct it
> > ourselves using the make-keys.sh script.
> >
> > * tools/dist/release.py
> > (roll_tarballs): Call make-keys.sh to create the KEYS file
> > (get_keys): Call make-key
dsahlb...@apache.org wrote on Fri, Jul 08, 2022 at 20:47:42 -:
> +++ subversion/trunk/tools/dist/release.py Fri Jul 8 20:47:42 2022
> @@ -980,7 +979,12 @@ def roll_tarballs(args):
> # from a committer's LDAP profile down the road)
> basename = 'subv
urselves using the make-keys.sh script.
>
> * tools/dist/release.py
> (roll_tarballs): Call make-keys.sh to create the KEYS file
> (get_keys): Call make-keys.sh to create the KEYS file
>
> Modified:
> subversion/trunk/tools/dist/release.py
>
> Modified: subversion/t
sing the make-keys.sh script.
>
> * tools/dist/release.py
> (roll_tarballs): Call make-keys.sh to create the KEYS file
> (get_keys): Call make-keys.sh to create the KEYS file
>
> Modified:
> subversion/trunk/tools/dist/release.py
>
> Modified: subversion/trunk/tool
On 10.04.2022 23:29, br...@apache.org wrote:
Author: brane
Date: Sun Apr 10 21:29:50 2022
New Revision: 1899719
URL: http://svn.apache.org/viewvc?rev=1899719&view=rev
Log:
* tools/dist/release.py:
- Generate public key algorithm names in the same format as GnuPG 2.
- Support DSA and
Daniel Shahaf wrote:
Can't we just do this? —
def recommended_release(version_being_rolled, versions_on_dist_release):
stable_versions_on_dist_release = filter(lambda v: not
v.is_prerelease(), versions_on_dist_release)
if version_being_rolled.is_prerelease():
ret
gt; > URL: http://svn.apache.org/viewvc?rev=1869981&view=rev
> > > Log:
> > > * tools/dist/release.py (recommended_release): Remove TODO: didn't make
> > > sense.
> >
> > The point of that TODO is that instead of hardcoding
> > «recommended
Daniel Shahaf wrote:
julianf...@apache.org wrote on Mon, 18 Nov 2019 16:31 +00:00:
Author: julianfoad
Date: Mon Nov 18 16:31:45 2019
New Revision: 1869981
URL: http://svn.apache.org/viewvc?rev=1869981&view=rev
Log:
* tools/dist/release.py (recommended_release): Remove TODO: didn't m
Daniel Shahaf wrote:
julianf...@apache.org wrote on Mon, 18 Nov 2019 17:00 +00:00:
+++ subversion/trunk/tools/dist/release.py Mon Nov 18 17:00:16 2019
@@ -70,43 +71,22 @@ except ImportError:
+# Read the dist metadata (about release lines)
+with open(get_dist_metadata_file_path(), 'r')
julianf...@apache.org wrote on Mon, 18 Nov 2019 17:00 +00:00:
> +++ subversion/trunk/tools/dist/release.py Mon Nov 18 17:00:16 2019
> @@ -70,43 +71,22 @@ except ImportError:
> +# Read the dist metadata (about release lines)
> +with open(get_dist_metadata_file_path(),
julianf...@apache.org wrote on Mon, 18 Nov 2019 16:31 +00:00:
> Author: julianfoad
> Date: Mon Nov 18 16:31:45 2019
> New Revision: 1869981
>
> URL: http://svn.apache.org/viewvc?rev=1869981&view=rev
> Log:
> * tools/dist/release.py (recommended_release): Remove TODO: didn
Daniel Shahaf wrote:
Julian Foad wrote on Tue, 29 Oct 2019 20:54 +00:00:
At a quick try I couldn't get either "time.strptime" nor
"datetime.strptime" to work. The latter says "AttributeError: [...]
Thanks, r1869134. The AttributeError was likely because the function's
fully-qualified name is
James McCoy wrote on Wed, 30 Oct 2019 02:03 +00:00:
> On Tue, Oct 29, 2019 at 11:21:04PM -, danie...@apache.org wrote:
> > +abort
>--^
> Left over debug code?
Yes, thanks. Fixed in r1869139.
On Tue, Oct 29, 2019 at 11:21:04PM -, danie...@apache.org wrote:
> Author: danielsh
> Date: Tue Oct 29 23:21:04 2019
> New Revision: 1869134
>
> URL: http://svn.apache.org/viewvc?rev=1869134&view=rev
> Log:
> * tools/dist/release.py
> (write_news): Validat
Julian Foad wrote on Tue, 29 Oct 2019 20:54 +00:00:
> Daniel Shahaf wrote:
> > release_date = time.strptime(args.news_release_date, "-mm-dd") if
> > args.news_release_date else datetime.date.today()
> > … { 'date': release_date.strftime("mmdd"),
> > 'date_pres': release_date.strftime(
Daniel Shahaf wrote:
You don't do any input validation on the date in argv anywhere, so
Right. I'm not wanting to spend much time on niceties as I want to
change a lot of this to read data from somewhere else, but then it still
might want validating at this level.
[...]
release_date = tim
julianf...@apache.org wrote on Tue, 29 Oct 2019 17:22 +00:00:
> +++ subversion/trunk/tools/dist/release.py Tue Oct 29 17:22:40 2019
> @@ -1188,8 +1188,9 @@ def move_to_dist(args):
> def write_news(args):
> 'Write text for the Subversion website.'
> -data = {
Daniel Shahaf wrote:
> julianf...@apache.org wrote on Thu, 26 Sep 2019
> > -svn_repos = 'https://svn.apache.org/repos/asf/subversion'
> > -dist_repos = 'https://dist.apache.org/repos/dist'
> > +svn_repos = 'file:///opt/svn/dummy-asf-repos/svn-repo/subversion'
> > +dist_repos = 'file:///opt/svn/d
On Fri, Oct 5, 2018 at 5:26 PM Daniel Shahaf wrote:
>
> Daniel Shahaf wrote on Fri, 05 Oct 2018 14:28 +:
> > It should instead do two things: one, fetch the log message of the
> > mentioned revision(s) (r1842260) and pass it through the existing
> > "Extract CHANGES summary" logic; two, parse
Daniel Shahaf wrote on Fri, 05 Oct 2018 14:28 +:
> It should instead do two things: one, fetch the log message of the
> mentioned revision(s) (r1842260) and pass it through the existing
> "Extract CHANGES summary" logic; two, parse the STATUS entry embedded in
> the log message, as in the attac
'release.py write-changelog --include-unlabeled-summaries' generates
CHANGES text from 'svn mergeinfo' output on the stable branch. For
merge revisions (such as those committed by svn-role), it currently
picks the first line of the log message, e.g., "Merge r1842260
Julian Foad wrote on Sat, 14 Apr 2018 18:21 +0100:
> Daniel Shahaf wrote on 2018-04-14:
> > > It's because it uses "svnmucc -r put <...>" but STATUS has already
> > > been modified between r and HEAD.
> >
> > Agreed. It's perfectly possible for the branch to have changed between the
> > magic r
d HEAD. When editing STATUS, the base revision (argument to
> the -r option) should be HEAD resolved to a number.
>
> Something like this, perhaps?
I agree the semantics you propose is/are correct. The patch looks right,
inspecting the diff; I haven't tested it.
- Julian
> [[[
&
Julian Foad wrote on Wed, Apr 11, 2018 at 08:21:19 +0100:
> Running "release.py create-tag" just now failed:
>
> + release.py --base-dir /opt/svnrm create-tag 1.10.0 r1827917
> INFO:root:Creating tag for 1.10.0
> r1828867 committed by julianfoad at 2018-04-11T07:00:33.54
Running "release.py create-tag" just now failed:
+ release.py --base-dir /opt/svnrm create-tag 1.10.0 r1827917
INFO:root:Creating tag for 1.10.0
r1828867 committed by julianfoad at 2018-04-11T07:00:33.547290Z
INFO:root:Bumping revisions on the branch
.../subversion/svnmucc/svn
Op 22 dec. 2017 00:53 schreef "Johan Corveleyn":
Also, feel free to improve the code ... I'm far from a python expert
(depending heavily on copy-paste and StackOverflow).
To clarify about the provenance of the code: I didn't actually copy-paste
anything. I was merely joking to illustrate my skil
After some further thought and tweaking, I committed a write-changelog
function in r1818988.
I tried to make it flexible enough so we can experiment a bit with it.
- The "changes labels" can be used as prefix or suffix.
- They can be [U:client], [D:api], ... or [U], [D], or simply []
- There's an
On Thu, Dec 14, 2017 at 6:58 PM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Mon, Dec 04, 2017 at 12:16:37 +0100:
>> As promised on IRC last Friday, here is a POC implementation of the
>> "generate changelog from commit messages" functionality,
>
> We had some more discussion about this on IRC
Daniel Shahaf wrote:
[...]
explicitly indicate "This commit shouldn't be added to CHANGES",
[...]
WDYT?
Rather than "This should (or should not) be listed in our specific
'CHANGES' file", the semantics of an annotated log message summary
should be "This change is (or is not) externally s
Johan Corveleyn wrote on Mon, Dec 04, 2017 at 12:16:37 +0100:
> As promised on IRC last Friday, here is a POC implementation of the
> "generate changelog from commit messages" functionality,
We had some more discussion about this on IRC last Monday¹; I'll try to
summarize.
Goal: reduce the worklo
d converge, then sure, this could be
a good idea. If not, I think we haven't gained much (the RM would have
to rephrase them all anyway).
For example, CHANGES for 1.10 contains (just taking a couple of
entries under User-visible "Minor new features and improvements"):
* New
On 04.12.2017 23:01, Julian Foad wrote:
> Johan Corveleyn wrote:
>> [...]
>> Hm, yes, I agree with the "don't write the same thing twice". But
>> perhaps the "general description" above the list of affected files
>> would be a better place:
> [...]
>> Though, indeed, we're not required to always ha
Johan Corveleyn wrote on Tue, 05 Dec 2017 00:04 +0100:
> On Mon, Dec 4, 2017 at 11:01 PM, Julian Foad wrote:
> > Johan Corveleyn wrote:
> >> Just thinking out loud here ...
> >
> > [...]> H
> >
> > Now you're over-thinking it. What you said first, what you use at work, is
> > fine. Run with it
On Mon, Dec 4, 2017 at 11:01 PM, Julian Foad wrote:
> Johan Corveleyn wrote:
>>
>> [...]
>> Hm, yes, I agree with the "don't write the same thing twice". But
>> perhaps the "general description" above the list of affected files
>> would be a better place:
>
> [...]
>>
>> Though, indeed, we're not
Johan Corveleyn wrote:
[...]
Hm, yes, I agree with the "don't write the same thing twice". But
perhaps the "general description" above the list of affected files
would be a better place:
[...]
Though, indeed, we're not required to always have a "general
description", and can just start with the
On Mon, Dec 4, 2017 at 3:15 PM, Julian Foad wrote:
> Stefan Sperling wrote:
>>
>> Johan Corveleyn wrote:
>>>
>>> The intention is that the RM doesn't need to go through all the full
>>> log messages in detail, but that he can trust the output of
>>> write-changelog, combined with trust in the qual
Stefan Sperling wrote:
Johan Corveleyn wrote:
The intention is that the RM doesn't need to go through all the full
log messages in detail, but that he can trust the output of
write-changelog, combined with trust in the quality of the log
messages involved.
OK, in that light it all makes sense
On Mon, Dec 04, 2017 at 02:17:59PM +0100, Johan Corveleyn wrote:
> > I believe that whatever we do, somebody will still have to read the full log
> > and check each entry in CHANGES to avoid listing a lot of trivial stuff,
> > and to make sure the most impactful changes appear at the top.
>
> I do
On Mon, Dec 4, 2017 at 1:45 PM, Stefan Sperling wrote:
> On Mon, Dec 04, 2017 at 12:16:37PM +0100, Johan Corveleyn wrote:
>> Examples:
>> [U:major] Better interactive conflict resolution for tree conflicts
>> [U:minor] ra_serf: Adjustments for serf versions with HTTP/2 support
>> [U:client]
On Mon, Dec 04, 2017 at 12:16:37PM +0100, Johan Corveleyn wrote:
> Examples:
> [U:major] Better interactive conflict resolution for tree conflicts
> [U:minor] ra_serf: Adjustments for serf versions with HTTP/2 support
> [U:client] Fix 'svn diff URL@REV WC' wrongly looks up URL@HEAD (issue #45
As promised on IRC last Friday, here is a POC implementation of the
"generate changelog from commit messages" functionality, added to
release.py (I'm not very experienced in Python; I mainly depend on
google, SO, copy-paste, ... so don't focus on coding style etc).
This
On 8/17/2017 13:44, br...@apache.org wrote:
> Author: brane
> Date: Thu Aug 17 11:44:50 2017
> New Revision: 1805277
>
> URL: http://svn.apache.org/viewvc?rev=1805277&view=rev
> Log:
> Add stricter key file syntax checks for releases.
>
> * tools/dist/release.py (g
On 8/9/2017 22:09, phi...@apache.org wrote:
> Author: philip
> Date: Wed Aug 9 20:09:51 2017
> New Revision: 1804608
>
> URL: http://svn.apache.org/viewvc?rev=1804608&view=rev
> Log:
> * tools/dist/release.py: Set TZ to UTC so timezones in tarballs do not
>
phi...@apache.org wrote on Thu, 10 Aug 2017 18:48 +:
> URL: http://svn.apache.org/viewvc?rev=1804705&view=rev
> Log:
> download.html: Restore template.
>
> +++ subversion/site/publish/download.html Thu Aug 10 18:48:29 2017
> @@ -99,7 +99,7 @@ Other mirrors:
> -Apache Subversion 1.9.7
> +Apache
On 02.07.2017 08:53, Daniel Shahaf wrote:
> danie...@apache.org wrote on Sun, 02 Jul 2017 06:45 +:
>> release.py: When parsing signatures (for check-sigs and write-announcement),
>> use the machine-readable output format. This adds support for ${PATH}/gpg
>> being gp
danie...@apache.org wrote on Sun, 02 Jul 2017 06:45 +:
> release.py: When parsing signatures (for check-sigs and write-announcement),
> use the machine-readable output format. This adds support for ${PATH}/gpg
> being gpg2; up to now, it was assumed to be gpg1.
>
> The outpu
phi...@apache.org wrote on Wed, May 09, 2012 at 21:36:23 -:
> +subparser.add_argument('--username', default=getpass.getuser(),
> +help='''Username for ''' + dist_repos + '''. The default
> +is the current username''')
I think the default sho
On Mon, Mar 26, 2012 at 11:02:48AM -0400, Greg Stein wrote:
> On Mon, Mar 26, 2012 at 09:43, wrote:
> >...
> > +++ subversion/trunk/tools/dist/release.py Mon Mar 26 13:43:47 2012
> > @@ -21,10 +21,10 @@
> >
> >
> > # About this script:
> > -#
On Mon, Mar 26, 2012 at 09:43, wrote:
>...
> +++ subversion/trunk/tools/dist/release.py Mon Mar 26 13:43:47 2012
> @@ -21,10 +21,10 @@
>
>
> # About this script:
> -# This script is intended to simplify creating Subversion releases, by
> -# automating as much as is
On Wed, Jul 13, 2011 at 4:21 PM, Greg Stein wrote:
> On Wed, Jul 13, 2011 at 13:11, wrote:
>> Author: hwright
>> Date: Wed Jul 13 17:11:42 2011
>> New Revision: 1146143
>>
>> URL: http://svn.apache.org/viewvc?rev=1146143&view=rev
>> Log:
>> * to
On Wed, Jul 13, 2011 at 13:11, wrote:
> Author: hwright
> Date: Wed Jul 13 17:11:42 2011
> New Revision: 1146143
>
> URL: http://svn.apache.org/viewvc?rev=1146143&view=rev
> Log:
> * tools/dist/release.py
> (roll_tarballs): One more special case for the 'nightl
On Wed, Jul 13, 2011 at 15:00, wrote:
> Author: hwright
> Date: Wed Jul 13 19:00:15 2011
> New Revision: 1146228
>
> URL: http://svn.apache.org/viewvc?rev=1146228&view=rev
> Log:
> release.py: String-ify the Version objects for use by ezt. (I would have
> thought t
On Mon, Jun 27, 2011 at 3:39 PM, Greg Stein wrote:
> On Mon, Jun 27, 2011 at 13:53, wrote:
>>...
>> +++ subversion/trunk/tools/dist/templates/stable-release-ann.ezt Mon Jun 27
>> 17:53:54 2011
>> @@ -0,0 +1,32 @@
>> +I'm happy to announce Subversion [version], available from:
>> +
>> + http:
On Mon, Jun 27, 2011 at 13:53, wrote:
>...
> +++ subversion/trunk/tools/dist/templates/stable-release-ann.ezt Mon Jun 27
> 17:53:54 2011
> @@ -0,0 +1,32 @@
> +I'm happy to announce Subversion [version], available from:
> +
> + http://subversion.tigris.org/downloads/subversion-[version].tar.bz
On Mon, Jun 27, 2011 at 3:17 PM, Greg Stein wrote:
> On Mon, Jun 27, 2011 at 13:44, wrote:
>>...
>> +++ subversion/trunk/tools/dist/release.py Mon Jun 27 17:44:05 2011
>> @@ -108,6 +108,13 @@ def download_file(url, target):
>> target_file = open(target,
On Mon, Jun 27, 2011 at 13:44, wrote:
>...
> +++ subversion/trunk/tools/dist/release.py Mon Jun 27 17:44:05 2011
> @@ -108,6 +108,13 @@ def download_file(url, target):
> target_file = open(target, 'w')
> target_file.write(response.read())
>
> +def split
On Thu, Jun 16, 2011 at 9:38 PM, Greg Stein wrote:
> On Thu, Jun 16, 2011 at 16:24, wrote:
>>...
>> @@ -250,6 +256,60 @@ def roll_tarballs(base_dir, args):
>> if not dep.have_usable():
>> raise RuntimeError('Cannot find usable %s' % dep.label)
>>
>> + # Make sure CHANGES is
On Thu, Jun 16, 2011 at 16:24, wrote:
>...
> @@ -250,6 +256,60 @@ def roll_tarballs(base_dir, args):
> if not dep.have_usable():
> raise RuntimeError('Cannot find usable %s' % dep.label)
>
> + # Make sure CHANGES is sync'd
> + if not branch == 'trunk':
Boy. That's a conv
Hyrum K Wright wrote on Sat, Jun 11, 2011 at 04:01:07 -0500:
> On Fri, Jun 10, 2011 at 7:49 PM, Daniel Shahaf
> wrote:
> > hwri...@apache.org wrote on Sat, Jun 11, 2011 at 00:14:03 -:
> >> +# About this script:
> >> +# This script is intended to simplify creating Subversion releases, by
> >
On Fri, Jun 10, 2011 at 7:49 PM, Daniel Shahaf wrote:
> hwri...@apache.org wrote on Sat, Jun 11, 2011 at 00:14:03 -:
>> +# About this script:
>> +# This script is intended to simplify creating Subversion releases, by
>> +# automating as much as is possible. It works well with our Apache
>
hwri...@apache.org wrote on Sat, Jun 11, 2011 at 00:14:03 -:
> +# About this script:
> +# This script is intended to simplify creating Subversion releases, by
> +# automating as much as is possible. It works well with our Apache
> +# infrastructure, and should make rolling, posting, and
67 matches
Mail list logo