Release Distribution
Preamble
Some thoughts about fixing the issue of distributing incubator releases.
This is a draft document. Needs to be discussed on general and agreed with infra. Please feel free to jump in.
Workflow
Current Podlings
Name |
Old Release Archived? |
Current Release In Dist? |
Abdera |
|
|
Buildr |
|
|
|
|
|
Composer |
|
|
Graffito |
|
|
JSPWiki |
|
|
JuiCE |
|
|
log4php |
|
|
Lokahi |
|
|
Lucene.Net |
|
|
NMaven |
|
|
Pig |
|
|
Qpid |
|
|
RCF |
|
|
River |
|
|
Sanselan |
|
|
Shindig |
|
|
Sling |
|
|
stdcxx |
|
|
Tika |
|
|
|
|
|
Tuscany |
|
|
UIMA |
|
|
WSRP4J |
|
|
XAP |
|
|
Yoko |
|
N/A |
Archiving Releases For Old Podlings
Graduated Podlings
Releases for graduated podlings will be archived directly with .htaccess redirect from original URL. A README will be added to note the status of the podling and that the provenance of these releases needs to be cross checked. An email should be sent to the dev mailing list informing them of this change.
Podling |
Created Archive Directory |
Copied Releases |
Deleted Originals |
Redirected Traffic |
Emailed dev |
|
|
|
|
|
|
Ivy |
|
|
|
|
|
ActiveMQ |
|
|
|
|
|
Apollo |
|
|
|
|
|
Beehive |
|
|
|
|
|
XMLBeans |
|
|
|
|
|
|
|
|
|
|
|
Geronimo |
|
|
|
|
|
Pluto |
|
|
|
|
|
Hermes |
|
|
|
|
|
Jackrabbit |
|
|
|
|
|
|
|
|
|
|
|
jUDDI |
|
|
|
|
|
|
|
|
|
|
|
Muse |
|
|
|
|
|
Tapestry |
|
|
|
|
|
Tobago |
|
|
|
|
|
Lenya |
|
|
|
|
|
log4cxx |
|
|
|
|
|
httpd-CLI |
|
|
|
|
|
Directory |
|
|
|
|
|
iBATIS |
|
|
|
|
|
|
|
|
|
|
|
Nutch |
|
|
|
|
|
Derby |
|
|
|
|
|
JDO |
|
|
|
|
|
WebWork 2 |
|
|
|
|
|
Harmony |
|
|
|
|
|
OFBiz |
|
|
|
|
|
Cayenne |
|
|
|
|
|
Synapse |
|
|
|
|
|
Solr |
|
|
|
|
|
Trinidad |
|
|
|
|
|
Roller |
|
|
|
|
|
log4net |
|
|
|
|
|
OpenEJB |
|
|
|
|
|
Felix |
|
|
|
|
|
OpenJPA |
|
|
|
|
|
mod_ftp |
|
|
|
|
|
Wicket |
|
|
|
|
|
Woden |
|
|
|
|
|
Ode |
|
|
|
|
|
|
|
|
|
|
Retired Podlings
Releases should be archived directly with an .htaccess redirect. A README should be added explaining that the podling has been retired and that the exact status and provenance of these releases needs to be cross checked.
Podling |
Created Archive Directory |
Copied Releases |
Deleted Originals |
Redirected Traffic |
Agila |
|
|
|
|
AltRMI |
|
|
|
|
Axion |
|
|
|
|
Depot |
|
|
|
|
Heraldry |
|
|
|
|
Kabuki |
|
|
|
|
Lucene4c |
|
|
|
|
TSIK |
|
|
|
|
wadi |
|
|
|
|
Existing Releases
Status
Existing incubator releases are scattered
Need to conduct an audit of locations of existing releases for projects. This probably means asking projects to fill something in on the wiki.
To Mirror Or Not To Mirror
- Mirroring reduces bandwidth only when the bandwidth of the archives downloaded exceeds the bandwidth cost of uploading releases to the mirrors
- The Incubator contains a large number of podlings. This is likely to cause a major bandwidth spike.
- It may be worth considering archiving all releases and then mirroring just new ones.
New Releases
Mirroring Strategy
New releases should be mirrored. This means deciding the best approach to the download mirroring scripts.
Options:
- Ask podlings to create their own scripts and audit them
- Create central scripts
- Basic ones
- Sophisticated XSLT scripts (as pioneered by Jakarta) which also eg. push news. Meta-data?
Signing Strategy
One weakness is that podling release managers rarely have strongly connected signatures. It is also possible that podlings may end up having no long term future@Apache. All release managers for a project may become inactive as well as being unconnected.
- Does the incubator need to think about IPMC signatures?
- Do the KEYS need to be maintained in a central location?
Permissions
Set these on a per podling basis?