On Sun, Apr 10, 2022 at 9:45 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote:
>
> Daniel Sahlberg wrote on Mon, Mar 28, 2022 at 21:55:36 +0200:
> > Den mån 28 mars 2022 kl 09:55 skrev Daniel Sahlberg <
> > daniel.l.sahlb...@gmail.com>:
> >
> > > This commit doesn't look correct.
> > >
> > > I executed the generate-upcoming-changes-log.sh manually yesterday and it
> > > created r1899244, removing a lot of log entries belonging to 1.14.1. This
> > > commit (which was executed by cron) restores them.
> > >
> > > The crontab entry is:
> > > [[[
> > > # Puppet Name: Update our upcoming changes list
> > > SVN=svn
> > > 15 4 * * * chronic ~/src/svn/site/tools/generate-upcoming-changes-log.sh
> > > ]]]
> > >
> > > The script begins with a comment
> > > [[[
> > > # This should be run from the root of a branches/1.{9,10,11}.x working
> > > copy.
> > > ]]]
> > >
> > > I suppose the crontab command should be changed to:
> > > cd ~/src/svn/1.14.x && chronic
> > > ~/src/svn/site/tools/generate-upcoming-changes-log.sh
> > >
> >
> > So I've investigated this further and my initial analysis seems correct.
> >
> > This is what happens:
> > * generate-upcoming-changes-log.sh determines last patch release number and
> > generates upcoming.part.html based on all commits since that patch release
> > was tagged.
> > * It has two different ways to determine "the last patch release":
> > * If `cwd` is a WC it look in the subversion/include/svn_version.h
> > * Else look in https://dist.apache.org/repos/dist/release/subversion/
> > * The logic looking at dists.a.o selected the oldest patch release
> > available on dists.a.o, in case there are more than one.
> > * The crontab entry executed generate-upcoming-changes-log.sh from ~, thus
> > forcing a lookup from dists.a.o
> >
> > Currently, both 1.14.0 and 1.14.1 are available on dists.a.o. Thus it
> > emitted all merged changes since 1.14.0, while expected behaviour (of
> > upcoming.part.html) would be to only display merged changes since 1.14.1.
> >
>
> dist/ should only contain the latest release from each supported minor
> line, except when a release is being staged. I.e., today it should
> contain 1.14.2 and 1.14.1 since we're in the process of staging 1.14.2;
> but by Friday it should contain 1.14.2 and 1.10.8 and only those two.
>
> The script relies on this. Thus, if we'd deleted 1.14.0's artifacts
> when we released 1.14.1 and kept the cron job as it was, the output
> would then have been correct (and we wouldn't have had an extra manual
> step in our create-a-A.B.x-branch workflow).
I am guessing he just did not realize this was the root cause. It
makes sense now what was happening.
You probably all saw I cleaned up those old releases and then put them
back. I was following the instructions in HACKING. I am not sure if
previous RM's decided to leave those behind or just did not follow
HACKING to the letter.
Anyway, I thought the documentation was ambiguous about WHEN you
should do this cleanup. I decided it should be done after the release
is announced which is why I put them back.
I am happy to do the cleanup later this week though.
Mark
