On Mon, Apr 11, 2022 at 7:27 AM Mark Phippard <markp...@gmail.com> wrote:
> 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
>
I've been trying to follow along and have learned a lot about releases
these last few weeks and your notes on the subject are very valuable. After
the release I would like to go through this part of HACKING and improve any
areas that led to questions etc. I think this will be very instructional,
as well, so hopefully I will be able to RM in the future.
Thanks for everything you have been doing.
Cheers,
Nathan
