Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
From: Julian Foad <julian_at_foad.me.uk>
Date: Fri, 13 Jul 2018 17:12:04 +0100
Stefan Hett wrote:
There are different possible set of changes we might want to list:
It looks like we have been doing (b) until now. That's fine, I just hadn't noticed, and was interpreting the documented instruction to "sync from trunk" as (c). I would be happy to have (b), or indeed (a).
I guess previous release managers merged the relevant changes manually to achieve this. I am looking for something more automatic.
How can we automatically merge only the changes in 'CHANGES' that pertain to 'this' branch and earlier minor-release-lines? Will some parsing be needed, either of the CHANGES file contents to determine which section is edited, or of commit messages to decide which revisions to cherry-pick?
> > Is maintaining CHANGES per release branch really so hard? Automation
If your 1.9 tarball instead directed you to follow a link to a CHANGES list, would you still then find it weird to see all changes including later ones listed there? Just asking, to shed more light on our expectations vs. real needs.
I thought making the changelogs in 1.9.8 and 1.10.1 tarballs exactly the same might be a rather nice property if they are released at the same time, but it is not important to me. Indeed, I too think it would be nice to see only the changes relevant to the version I have downloaded. But the question is, how easily can we do that? Would it be easier, and good enough, just to have one version of the list?
> Also for the proposed location to put things directly in the project
Have you looked? Are you prepared to change your mind when you see...?
$ svn ls ^/subversion
Brane's suggestion of locating CHANGES in the web site tree makes quite good sense to me too, although as long as both trees are accessible on the web it perhaps makes hardly any difference.
> That said, getting a working copy [...] would not be possible [...]
Woah, huh? Didn't you see my suggestion to replace 'trunk/CHANGES' with an external reference (quoted above)? The file would appear in a normal checkout of trunk (or any branch) and be editable and committable from there just as it is today.
> > FWIW, changing COMMITTERS is usually the first task we give to new
(Pfft! Why would it matter a jot if we change that exercise slightly? How would it change materially at all, come to that, if we use the 'file external' approach?)
> > It should not be too hard to make release.py do a sync-merge to the release
What exactly should it 'sync' merge, re. (a)/(b)/(c) above?
-- - JulianReceived on 2018-07-13 18:12:15 CEST
This is an archived mail posted to the Subversion Dev mailing list.