db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5388) Write tool to automate archive process for old release pages
Date Tue, 06 Sep 2011 16:33:09 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098142#comment-13098142

Rick Hillegas commented on DERBY-5388:

Thanks for the patch, Kristian. Your conversations with the infrastructure group may shed
light on some behaviors of our release management processes which have always confused me.

I see that the patch is coded in python. Every new tool we require the release manager to
understand reduces our pool of potential release managers. This was one of the problems I
had with the Eclipse plugins. We can figure out over time whether the python script runs flawlessly
every time (like Forrest, another tool I don't understand) or whether it needs tweaking per
release (like the Eclipse plugins).

A quick glance at the patch suggests that it may be attempting to automate step (b) in the
Description section of this JIRA. However, the header comment of the script suggests that
the patch intends to "modify web site to archive old release". Don't know what that means.
As I understand it, releases are archived almost immediately after they are posted under /www/www.apache.org/dist/db/derby.
Step (b) happens maybe six months later when the next release is posted. 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".

2) The "archives" are the machines/directories where Apache permanently stores release distributions.

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.

It's all a bit muddling to me, I'm afraid. I don't understand what makes old releases disappear
from the mirrors.


Addressing your question about whether this script should be run after the new release has
gone live and its downloads appear to be working:

+ An advantage of doing it that way is that it reduces the risk that users will be cut off
from older releases in case the new release links are broken and the python script does something

- A disadvantage of doing it that way is that the release manager has to remember to come
back later on to finish up the process. I think that increases the risk that the rele se manager
will forget this step.

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.


Addressing your question about when to switch downloads of a release from the mirrors to the

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.


> 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:
>            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.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message