Den mån 11 apr. 2022 kl 13:27 skrev Mark Phippard <markp...@gmail.com>:
> 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.
>
I realized this and I figured the chance/risk of RM forgetting to cleanup
justified to use the first way of detecting "latest patch release" (through
svn_version.h). Part of my investigation was to look at the log of dist/
and finding that this wasn't the first time that old releases were laying
around for a long time.
I agree that it makes sense to display the upcoming changes until the
release has been announced, in which case the change in puppet should be
reverted (or we should adjust the script for a better way detect "lastest
patch release". More below.
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.
>
As I read the documentation, you should cleanup as soon as the release is
uploaded, but hold back the announcement for 24 hours until the mirrors
have picked up the release. As far as I understand the mirror system at ASF
has been deprecated in favour of a CDN [1], where the CDN is supposed to
pick up the files "within 15 minutes" [2].
It is not immediately clear to me if cleaning up also disables downloading
the old release. If so, we have a 24 hour window when there are no
(announced) releases available for downloading. I have not investigated
this.
If we upload and immediately cleanup, then wait for 24 hours the upcoming
page will still display the "wrong" for one day. So the cleanup should
ideally not be done until after the release announcement. But it is an
additional thing to remember for the RM, so I can see why it is done the
same time as the upload. Mark, your input on this question is most valued!
That being said, I believe we could remove the 24 hours wait between upload
and announcement considering the "within 15 minutes" guarantee of the CDN.
/Daniel
[1] https://lists.apache.org/thread/6932rjo7jps7sdqr0h3bcfdm2zbw3sc3
[2] https://lists.apache.org/thread/0b3j0lmbjbrw0gw1vnnjrbc3owzpos7l
