Kristian Waagan commented on DERBY-5388:
I'm replying to some of your comments/questions below.
RH> Your conversations with the infrastructure group may shed light on
some behaviors of our release management processes which have always
KW> Not quite sure what you mean here. If you had anything specific in mind,
let me know.
RH> ... I think the word "archive" is a bit overloaded. Our release
documention uses this term for 3 distinct purposes:
1) Some of our release documentation refers to the Derby
distributions themselves (the tars and zips) as "archives".
KW> To me, these are release artifacts.
RH> 2) The "archives" are the machines/directories where Apache
permanently stores release distributions.
KW> Right - maybe we can use a term like "Apache software archive" to
RH> 3) "Archiving" is used to mean updating the download pages so that
they point at release distributions in the Apache archives rather
than on the mirrors.
KW> I agree this is confusing, as it also conflicts with the archiving
that ASF is doing automatically for us - copying deployed release
artifacts to the Apache software archive.
Do we have another word/term we can use for the process of disabling
mirroring and moving a release from one section to another in the
Derby download page?
RH> ... I don't understand what makes old releases disappear from the mirrors.
KW> See the last comment below.
RH> Currently, our publication instructions tell the release manager to
remove cgi scripts for the old releases at the same time that the new
release is posted. That seems to have worked well in the past but I may
be forgetting some release when this approach caused problems.
KW> In that case, I see no reason why to introduce another step in the
process - we can continue doing what we're doing now.
RH> I think we need to switch download pointers before the old releases
disappear from the archives. But I don't know what triggers that
disappearance. I don't understand what harm is caused by continuing
to point old releases at the mirrors.
KW> I suppose you meant "mirrors" in the first sentence above?
The Derby release artifacts are removed from the mirrors shortly after
we explicitly remove them from the main Apache dist directory.
Based on what the ASF infrastructure team has communicated, the harm
caused by not cleaning up the main dist directory is increased load
on parts of the Apache infrastructure and on the infrastructure of
the mirrors. Both ends have to pay in terms of increased network
traffic when the mirrors are syncing up, and both ends have to deal
store old software "nobody" is downloading anymore (at the ASF end,
this probably includes backup too).
> Write tool to automate archive process for old release pages
> Key: DERBY-5388
> URL: https://issues.apache.org/jira/browse/DERBY-5388 > Project: Derby
> Issue Type: Improvement
> Components: Web Site
> Affects Versions: 10.9.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: archive-release.py
> Although release files themselves are automatically copied to the ASF archive, several further actions most be taken to update the web site when a release is archived.
> In short:
> a) update the download page itself
> b) remove cgi script
> c) update links to point to the archive in the HTML file
> d) remove CGI-enabling code in the the HTML file
> I'm hoping steps b - d can be automated. It's not clear to me how/where to integrate this yet (i.e. in the ant targets in the code repos, or as a script in the web site repos), but I think the process we want to follow may dictate that. We probably don't want to remove existing, working pages/links before we have verified that the new ones are working. Verification takes a while, since we have to wait for the changes to propagate.
> The reason for this suggestion is that several issues have been logged by the ASF infra team for problems with the release pages. There has also been errors which are most likely caused by "finger trouble" when manually editing the web pages.