db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5388) Write tool to automate archive process for old release pages
Date Wed, 07 Sep 2011 10:17:10 GMT

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

Kristian Waagan commented on DERBY-5388:

Thanks, Rick.
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
    confused me.
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
    reduce confusion?

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