On 7/13/2018 4:28 PM, Branko Čibej wrote:
> 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.
I'm with brane on this one. I'd find it quite weird to download the 1.9
based source and get a changelog containing things which aren't in that
source tree I just downloaded (i.e. 1.10 changes).
Especially in light of the release process changes (wink: LTS version)
that point might even be considered more relevant thinking that we'd
release 1.10 versions which changelog files would be talking about
changes of a 1.12.1 version.
IMO documentation/references to 1.10 based changes have no place in
older releases.
Also for the proposed location to put things directly in the project
root (i.e. ^/subversion) I'd not favor this much. This doesn't look like
the right place to put things in (to me) and it defeats the clean
structure of the project root only containing trunk/branches/tags. That
said, getting a working copy to edit CHANGES/COMMITTERS would not be
possible anymore with the straight forward checkout approach (i.e. a
plain co of the subversion project would checkout all tags/branches -
yes I know, sparse checkouts are the way to go, but still it'd feel just
wrong to me to put it there; especially in light of new committers being
asked to edit the COMMITTERS file as their first "official" task...).
My favorite obviously would be option 2.
>
>> 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.
+1
> [...]
--
Regards,
Stefan Hett
Received on 2018-07-13 17:22:05 CEST