On 13/07/2018 18:12, Julian Foad wrote:
> Stefan Hett wrote:
>> On 7/13/2018 4:28 PM, Branko Čibej wrote:
>>> On 13.07.2018 16:19, Julian Foad wrote:
>>>> 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 ...
> There are different possible set of changes we might want to list:
> (a) only the changes actually present in the history of the present branch/tag;
> (b) the changes present in the history of the present branch/tag AND all minor release lines that began earlier than this one;
> (c) all changes.
>
> 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 wasn't aware this is what we apparently did for the last 2 releases of
1.9.x at least. Apparently it was handled differently (f.e. see
r1667486) and the CHANGES file of 1.8.x also contains all 1.7.x
changelog entries. TBH I'd personally preferred that approach, but if
there were reasons to change it at some time, I don't wanna reopen any
discussion about that.
> 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?
Hm... Cherry picking revisions has the problem of adding further
requirements on commits specific to just the single CHANGES file to
every developer. I.e. assume someone already prepares the changelog in
good faith to help the RM driving the next release and commits it
alongside other changelog entries targeted for the trunk version. That
will not work with cherry-picking given revision and hence would be
something we would have to disallow.
That said, I guess the easiest approach would be to have a script copy
over the whole CHANGES file from trunk and remove all lines above the
entry for the new release. That ensures that even other fixes (f.e. ones
like r1829275) would be kept in-sync between trunk and the branch(es)
which is likely something which might get overlooked to get added an
appropriate tag, if we'd work with commit log tags.
>
>>> 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). [...]
> 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.
Confusing is maybe the wrong word. It wouldn't confuse me since I'd be
aware of the process, but as a new user I'd kind of find it irritating
to read up about changes of a new version and be presented with things
not in that release.
I also looked up two other libraries which I found in my set of libs
which use overlapping releases (OpenSSL and SWIG) and both follow the
same principle of only stating these versions in their changelog files
of the versions up to the one being released (but not the changes of
later (already released) major versions). Maybe there are libs out there
following the other procedure, but at least I'm not aware of any such
example.
>
> 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
>> 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.
> Have you looked? Are you prepared to change your mind when you see...?
> [...]
>
> 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.
Ouch, obviously I didn't look at it before sending the reply but was
rather relying on my memory from the last time I looked at the
subversion repository root (which obviously tricked me - pardon my bad
memory).
Given that fact, disregard my point above please. I still don't quite
like the idea of putting COMMITTERS directly in the subversion project
root however. The readme file serves a purpose there, but adding more
files to the root just doesn't seem to be too clean, does it?
>
>> 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.
Read it, started writing my reply and forgot about it (that should teach
me not to write replies during my lunch break at work while reading up
on other articles alongside). So please disregard my point here as well.
>
>>> FWIW, changing COMMITTERS is usually the first task we give to new
>>> committers [...]
> (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?)
Again, please disregard. I just wanted to spell out all the potential
implications (regardless how small that argument was) so to make sure we
at least consider (and accept) these implications. But as you stated
with the external approach it's obviously a non-brainer then anyway.
>
>>> It should not be too hard to make release.py do a sync-merge to the release
>>> branch.
>> +1
> What exactly should it 'sync' merge, re. (a)/(b)/(c) above?
>
As mentioned above, I'd personally be in favor of:
(d) the changes present in the history of the present branch/tag AND all minor release lines that were released before or at the same time as this one;
unless it was a deliberate change to switch that process to (b) in which
case I'd be all for (b).
Regards,
Stefan
Received on 2018-07-14 02:22:01 CEST