You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@apache.org> on 2018/07/13 14:19:11 UTC
[RFC] Move CHANGES and COMMITTERS out of trunk/branches
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/.
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.
Precedent: we moved our web pages out of {trunk,...}/www/... to ^/subversion/site/... in the past.
Thoughts?
--
- Julian
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Branko Čibej <br...@apache.org>.
On 13.07.2018 19:43, Daniel Shahaf wrote:
> Julian Foad wrote on Fri, 13 Jul 2018 17:12 +0100:
>> $ svn ls ^/subversion
>> README
>> branches/
>> developer-resources/
>> site/
>> site-ng/
>> svn-logos/
>> tags/
>> trunk/
>> upstream/
>>
>> 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.
> Infra prefers that user-facing documentation be served from
> subversion.a.o, not from svn.a.o.
Sure, that's why we publish the web site, not serve it from the
repository. This is merely a discussion about whether we publish CHANGES
the same way.
-- Brane
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Fri, 13 Jul 2018 17:12 +0100:
> $ svn ls ^/subversion
> README
> branches/
> developer-resources/
> site/
> site-ng/
> svn-logos/
> tags/
> trunk/
> upstream/
>
> 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.
Infra prefers that user-facing documentation be served from
subversion.a.o, not from svn.a.o.
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Stefan Sperling <st...@apache.org>.
On Mon, Jul 16, 2018 at 05:49:53PM +0100, Julian Foad wrote:
> Julian Foad wrote:
> > Stefan Sperling wrote:
> > >I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually
> > >deleted any entries above the one for the release being prepared.
> > >
> > >This worked quite well for me and I never found it burdensome.
> >
> > That, or scripting that as Johan suggested, sounds fine for now.
>
> Actually the "sync merge" way isn't as automatic as I would like. The merge always conflicts when there is a new or modified trunk CHANGES entry for 1.10.x. Maybe --accept=mine-conflict would completely solve that. Haven't tested that.
It did always conflict for me as well.
I may have used --theirs-conflict, or perhaps the interactive file
merge with the "12" option which outputs both conflicting parts
back to back, and then edited the file. I don't remember exactly :)
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Stefan <lu...@posteo.de>.
On 17/07/2018 11:24, Branko Čibej wrote:
> On 17.07.2018 11:17, Stefan wrote:
>> That said, if the majority of the team is fine with a change, so will
>> I be in the end and won't argue against it.
> Correction: not "if the majority of the team etc." but "if the consensus
> of the team is etc." We don't do majority votes here. :)
>
> -- Brane
hehe --- I know. To rephrase my statement: I'll concent to the rest of
the team's opinion, if everybody would prefer such change, regardless of
my personal feelings. ;-)
Regards,
Stefan
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Branko Čibej <br...@apache.org>.
On 17.07.2018 11:17, Stefan wrote:
> That said, if the majority of the team is fine with a change, so will
> I be in the end and won't argue against it.
Correction: not "if the majority of the team etc." but "if the consensus
of the team is etc." We don't do majority votes here. :)
-- Brane
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Stefan <lu...@posteo.de>.
On 17/07/2018 10:37, Branko Čibej wrote:
> On 17.07.2018 10:05, Johan Corveleyn wrote:
>> On Tue, Jul 17, 2018 at 9:03 AM, Branko Čibej <br...@apache.org> wrote:
>>> On 16.07.2018 21:46, Johan Corveleyn wrote:
>>>> (why would CHANGES in a 1.9.x tarball need to contain changes of the
>>>> 1.8 line?)
>>> Because I, as an admin, want to see the whole relevant history in
>>> CHANGES when something breaks and I have to fix it.
>> Hm, okay.
>> However, Daniel had a good point about what's actually *relevant* history:
>>
>> On Mon, Jul 16, 2018 at 9:54 PM, Daniel Shahaf wrote:
>>> I see no reason for a 1.9.x tarball to contain the CHANGES stanzas of
>>> 1.8.y with y>1, since the contents of those sections are repeated under
>>> 1.9.x sections, but I do see a reason for 1.9.x to contain the 1.z.0
>>> CHANGES entries even for z<=8: bugfixes listed in those section are
>>> included in the subject tarball and aren't listed under any 1.9.x
>>> CHANGES section.
>> That means we could do the following:
>>
>> 1) trunk/CHANGES: only keep the changelog of every 1.x.0 version
>> (including the unreleased trunk changes for the future 1.x.0), no
>> 1.x.y sections with y > 0.
>>
>> 2) Every release branch starts with its normal branch copy of
>> trunk/CHANGES (containing all 1.x.0 changelogs until then). With every
>> patch release, only the corresponding branch copy is updated (not
>> trunk, and not any other release branches).
>>
>> Would that work? No more merging, and every release branch (and tag /
>> tarball) has the preceding minor releases plus all relevant patch
>> releases.
>>
>> The only downside I see is that trunk/CHANGES no longer contains the
>> entire changelog of all our patch releases. Is that really necessary?
> Depends. For software archaeologists — and as our own aide-mémoire — it
> would be nice to have the changelog in one place. After all, it's an
> editorial work that's far more useful than a simple 'svn log'. Breaking
> all that historical info across who knows how many branches seems like a
> step backwards; analogous how to breaking up a single large repository
> into thousands of tiny modules would make version control harder
> (gitficionados, please note).
>
> -- Brane
+1 on that
There are quite a lot of benefits of having a complete changelog
available even for bugfix releases of previous minor releases. I
certainly can't come up with all and I also can't think of any "big"
ones which one would argue in the end outweights the hassle for the
release overhead. But then the release overhead isn't that much work
either as far as I see it (speaking here maybe of ~30 mins even for a
coordinated release for two versions, right?).
Just some examples where I used it myself in the past:
* looking up the changelog in my local installation to see if a user
reported issue (be it on the mailing list or at work) was resolved
in his older SVN version already
* identifying issues which were already fixed on the current version's
branch but were not yet backported to the previous version
* just reading up old changelog entries out of interest
As stated, none of these are major arguments against changing our
process, but still I'd personally miss a complete changelog. That said,
if the majority of the team is fine with a change, so will I be in the
end and won't argue against it.
Regards,
Stefan
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Branko Čibej <br...@apache.org>.
On 17.07.2018 10:05, Johan Corveleyn wrote:
> On Tue, Jul 17, 2018 at 9:03 AM, Branko Čibej <br...@apache.org> wrote:
>> On 16.07.2018 21:46, Johan Corveleyn wrote:
>>> (why would CHANGES in a 1.9.x tarball need to contain changes of the
>>> 1.8 line?)
>> Because I, as an admin, want to see the whole relevant history in
>> CHANGES when something breaks and I have to fix it.
> Hm, okay.
> However, Daniel had a good point about what's actually *relevant* history:
>
> On Mon, Jul 16, 2018 at 9:54 PM, Daniel Shahaf wrote:
>> I see no reason for a 1.9.x tarball to contain the CHANGES stanzas of
>> 1.8.y with y>1, since the contents of those sections are repeated under
>> 1.9.x sections, but I do see a reason for 1.9.x to contain the 1.z.0
>> CHANGES entries even for z<=8: bugfixes listed in those section are
>> included in the subject tarball and aren't listed under any 1.9.x
>> CHANGES section.
> That means we could do the following:
>
> 1) trunk/CHANGES: only keep the changelog of every 1.x.0 version
> (including the unreleased trunk changes for the future 1.x.0), no
> 1.x.y sections with y > 0.
>
> 2) Every release branch starts with its normal branch copy of
> trunk/CHANGES (containing all 1.x.0 changelogs until then). With every
> patch release, only the corresponding branch copy is updated (not
> trunk, and not any other release branches).
>
> Would that work? No more merging, and every release branch (and tag /
> tarball) has the preceding minor releases plus all relevant patch
> releases.
>
> The only downside I see is that trunk/CHANGES no longer contains the
> entire changelog of all our patch releases. Is that really necessary?
Depends. For software archaeologists — and as our own aide-mémoire — it
would be nice to have the changelog in one place. After all, it's an
editorial work that's far more useful than a simple 'svn log'. Breaking
all that historical info across who knows how many branches seems like a
step backwards; analogous how to breaking up a single large repository
into thousands of tiny modules would make version control harder
(gitficionados, please note).
-- Brane
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jul 17, 2018 at 9:03 AM, Branko Čibej <br...@apache.org> wrote:
> On 16.07.2018 21:46, Johan Corveleyn wrote:
>> (why would CHANGES in a 1.9.x tarball need to contain changes of the
>> 1.8 line?)
>
> Because I, as an admin, want to see the whole relevant history in
> CHANGES when something breaks and I have to fix it.
Hm, okay.
However, Daniel had a good point about what's actually *relevant* history:
On Mon, Jul 16, 2018 at 9:54 PM, Daniel Shahaf wrote:
> I see no reason for a 1.9.x tarball to contain the CHANGES stanzas of
> 1.8.y with y>1, since the contents of those sections are repeated under
> 1.9.x sections, but I do see a reason for 1.9.x to contain the 1.z.0
> CHANGES entries even for z<=8: bugfixes listed in those section are
> included in the subject tarball and aren't listed under any 1.9.x
> CHANGES section.
That means we could do the following:
1) trunk/CHANGES: only keep the changelog of every 1.x.0 version
(including the unreleased trunk changes for the future 1.x.0), no
1.x.y sections with y > 0.
2) Every release branch starts with its normal branch copy of
trunk/CHANGES (containing all 1.x.0 changelogs until then). With every
patch release, only the corresponding branch copy is updated (not
trunk, and not any other release branches).
Would that work? No more merging, and every release branch (and tag /
tarball) has the preceding minor releases plus all relevant patch
releases.
The only downside I see is that trunk/CHANGES no longer contains the
entire changelog of all our patch releases. Is that really necessary?
If so, can we find another solution for that?
(PS: I'm not trying to be pedantic / drag this on forever. Just trying
to explore whether things can be improved...)
--
Johan
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Branko Čibej <br...@apache.org>.
On 16.07.2018 21:46, Johan Corveleyn wrote:
> (why would CHANGES in a 1.9.x tarball need to contain changes of the
> 1.8 line?)
Because I, as an admin, want to see the whole relevant history in
CHANGES when something breaks and I have to fix it.
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Mon, 16 Jul 2018 21:46 +0200:
> (why would CHANGES in a 1.9.x tarball need to contain changes of the
> 1.8 line?)
I see no reason for a 1.9.x tarball to contain the CHANGES stanzas of
1.8.y with y>1, since the contents of those sections are repeated under
1.9.x sections, but I do see a reason for 1.9.x to contain the 1.z.0
CHANGES entries even for z<=8: bugfixes listed in those section are
included in the subject tarball and aren't listed under any 1.9.x
CHANGES section.
Cheers,
Daniel
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Jul 16, 2018 at 6:57 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Julian Foad wrote on Mon, 16 Jul 2018 17:49 +0100:
>> Actually the "sync merge" way isn't as automatic as I would like. The
>> merge always conflicts when there is a new or modified trunk CHANGES
>> entry for 1.10.x. Maybe --accept=mine-conflict would completely solve
>> that. Haven't tested that.
>
> We could have CHANGES-1.9, CHANGES-1.10, etc files, and as part of
> rolling a tarball concatenate them into a single (generated) CHANGES
> file. Then it would be much easier to merge just 1.9-and-earlier
> changes to 1.9, etc. (And it would save us writing a parser)
Or, along the same lines, like Julian suggested as third option in his
first mail in this thread:
> 3) Maintain change lists per branch: combine them programmatically
trunk/CHANGES: only contains future stuff (1.11 at this time)
1.10.x/CHANGES: only 1.10.0 and up
1.9.x/CHANGES: only 1.9.0 and up
...
When a new branch is created, it takes along the CHANGES file from
trunk (as it should), and we clear the CHANGES on trunk as part of
"post-branch housekeeping".
IMHO, no parsing needed, and no concatenation needed either (why would
CHANGES in a 1.9.x tarball need to contain changes of the 1.8 line?)
Hmmm, that would probably break scripts / links / workflows that
expect trunk/CHANGES to contain all of them ...
Maybe we could add a new BRANCH-CHANGES that fulfills the role
described above (only containing changes relevant to that branch),
also on trunk, and ... dunno, do something creative for providing the
concatenated CHANGES on the trunk/CHANGES url :-).
--
Johan
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Mon, 16 Jul 2018 17:49 +0100:
> Actually the "sync merge" way isn't as automatic as I would like. The
> merge always conflicts when there is a new or modified trunk CHANGES
> entry for 1.10.x. Maybe --accept=mine-conflict would completely solve
> that. Haven't tested that.
We could have CHANGES-1.9, CHANGES-1.10, etc files, and as part of
rolling a tarball concatenate them into a single (generated) CHANGES
file. Then it would be much easier to merge just 1.9-and-earlier
changes to 1.9, etc. (And it would save us writing a parser)
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Julian Foad <ju...@foad.me.uk>.
Julian Foad wrote:
> Stefan Sperling wrote:
> >I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually
> >deleted any entries above the one for the release being prepared.
> >
> >This worked quite well for me and I never found it burdensome.
>
> That, or scripting that as Johan suggested, sounds fine for now.
Actually the "sync merge" way isn't as automatic as I would like. The merge always conflicts when there is a new or modified trunk CHANGES entry for 1.10.x. Maybe --accept=mine-conflict would completely solve that. Haven't tested that.
Coincidentally, GitLab recently wrote about their similar bot not identical issue:
https://about.gitlab.com/2018/07/03/solving-gitlabs-changelog-conflict-crisis/
--
- Julian
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Julian Foad <ju...@foad.me.uk>.
On 14 July 2018 09:08:12 BST, Stefan Sperling <st...@apache.org> wrote:
>On Fri, Jul 13, 2018 at 05:12:04PM +0100, Julian Foad wrote:
>> I guess previous release managers merged the relevant changes
>manually to achieve this.
>
>I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually
>deleted any entries above the one for the release being prepared.
>
>This worked quite well for me and I never found it burdensome.
That, or scripting that as Johan suggested, sounds fine for now.
Thanks for discussing.
- Julian
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Stefan Sperling <st...@apache.org>.
On Fri, Jul 13, 2018 at 05:12:04PM +0100, Julian Foad wrote:
> I guess previous release managers merged the relevant changes manually to achieve this.
I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually
deleted any entries above the one for the release being prepared.
This worked quite well for me and I never found it burdensome.
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Stefan <lu...@posteo.de>.
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
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Julian Foad <ju...@foad.me.uk>.
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 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
> > 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.
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...?
$ svn ls ^/subversion
README
branches/
developer-resources/
site/
site-ng/
svn-logos/
tags/
trunk/
upstream/
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
> > 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?)
> > 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?
--
- Julian
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Stefan Hett <st...@egosoft.com>.
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
Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches
Posted by Branko Čibej <br...@apache.org>.
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