On 13.07.2018 16:19, Julian Foad wrote:
> Our releasing docs say, "CHANGES should always be edited on trunk and then merged over to the release branch(es)". The 'CHANGES' file in 1.10.1 doesn't have the latest two fixes that were merged to 1.10.x last night, because I missed manually re-executing that step.
>
> Possible improvements:
> 1) Have just one copy of 'CHANGES': move it out of trunk/branches
> 2) Automate more: make release.py do this sync-merge
> 3) Maintain change lists per branch: combine them programmatically
>
> Thinking about option 1,
>
> jcorvel wrote:
>> I'm wondering why we have in fact a copy of CHANGES in every branch / tag, since it contains a log of all releases, not only the particular branch that contains it. Wouldn't it be easier to have CHANGES outside of trunk/branches/tags, or at the "branches" root directory, so we only have a single CHANGES file? That would eliminate all the merging overhead to keep things in sync.
> To ensure a copy of it still goes into each release tarball, the release procedure can copy it in.
>
> One argument I heard recently for keeping things like this inside the trunk/branches was so it's easily available to anyone who is committing a change -- it will be in their WC. Could we fix that problem by having an in-repository 'external' pointing to it? I think this would work well:
>
> svn mv ^/subversion/trunk/CHANGES ^/subversion/CHANGES
> svn ps svn:externals '^/subversion/CHANGES CHANGES' trunk-wc/.
This would be mildly horrible as it would show up in release branches
and become part of the release. Up to now, CHANGES for release branches
did not contain info about trunk or later release branches, only
previous ones ...
Is maintaining CHANGES per release branch really so hard? Automation
sounds nice, except that we tend to update CHANGES at release time.
> The same applies to the 'COMMITTERS' file. I checked it just now and found that both 1.9.x and 1.10.x versions contained obsolete details for several committers including myself. I have now sync-merged it to both branches, but we could avoid the need to repeatedly do that in future by moving it out.
FWIW, changing COMMITTERS is usually the first task we give to new
committers ... it's sort of easier for them to have that on trunk. It
should not be too hard to make release.py do a sync-merge to the release
branch.
> Precedent: we moved our web pages out of {trunk,...}/www/... to ^/subversion/site/... in the past.
If you do want to move CHANGES and COMMITTERS out of trunk, then I
suggest moving both files to the website tree. Having the detailed
change log published on the web site makes a kind of sense. Not so much
COMMITTERS info, which tends to have real e-mail addresses in it ...
(and we should probably change that, too).
-- Brane
Received on 2018-07-13 16:28:10 CEST