Stale documents
Stale Documents
This page is reserved as a forum where twiki users can list stale documents. A stale document is one which either (a) service no purpose or (b) could serve some purpose, but is currently defective in some major regard.
Please list stale documents here, where they can be discussed in the weekly operations meeting (EVO /Tuesdays/11:00 am).
| Doc | Desc | Date of
entry |
Remark | Recommendation |
|---|---|---|---|---|
| [1] | SL4 Survey, August 2011 | 25 Feb 2013 | Sl4 Obsolete | Pending discussion |
| Middleware_transition | gLite to UMD/EMI middleware transition | 25 Feb 2013 | Purpose served. | Pending discussion.
|
| Glite software builds | Supposedly lists some builds | 2 July 2012 | It points to a dead end. Either connect it up, or get rid? | Pending discussion. |
| Yaim_-_GridPP_specific_settings | Some YAIM Settings | 2 July 2012 | It is stale. Should I do it up? Maybe. Consensus please. | Pending discussion.
|
| Site_information | Ostensibly, a statement of each site's memory and core configuration. | 2 July 2012 | This is one of a number of pages that (by the looks of things) site
admins are expect to fill out. In this particular case, I would suggest that this data should be rolled out and made public via the standard BDII information system, making this page obsolete. In the more general case, I would suggest that we should restructure all these pages. A better structure would be a page for each site, perhaps beneath T2 regions. If we did that, we could legitimately make each page an individual Key Doc, and assign it to the site admin. This works around trouble in the system, whereby "smeared documents" (as these are) can't be Key Docs because many people edit them. A Key Doc must have one main owner. I necessary, I can write a Perl script to split the data out into discrete sections for each which would be generated automatically from the site-specific data. The pages involved would be: Middleware_transition, Site_information, HEPSPEC06 (TBD), Site_status_and_plans, Protected_Site_networking, Resiliency_and_Disaster_Planning, SL4_Survey,_August_2011 (TBD) |
Pending discussion. |
| Current_VO_Fairshares_at_T2/T1 | Don't know | 2 July 2012 | Too stale for words | Pending discussion
|
| ATLAS_Software_Installation | Manual software installation | 2 July 2012 | Obsolete following CVMFS | Pending discussion
|
| Security_monitoring/updates | Don't know | 2 July 2012 | Too stale for words | Pending discussion
|
| Non_LHC_VO_Status_and_Plans | Some kind of project plan? | 30 July 2012 | No content | Pending discussion |
| Example_Build_of_an_EMI-UMD_Cluster | Rethink this - Sussex said it was useful. | 10 Feb 13 | Lot's of content | Pending discussion - maybe keep, but not a key doc?
|
Links to deleted material
This page contains the final resting place of documents that have been "deleted".
| Doc | Desc | Date of
entry |
Remark | Final State
|
|---|---|---|---|---|
| SAM_documentation | Renounced by Kashif | 7 May 2013 | serves no purpose. Not a key doc. | Deleted
|
| Update_tools | Supposedly a set of links to various tools | 2 July 2012 | Empty - serves no purpose at all. Suggest to delete. | Deleted |
| Workarounds_for_gLite3_on_SC4 | SL4 64-bit with gLite3 | 2 July 2012 | No-one use SL4, no one uses glite3. Ergo, it's useless. | Deleted
|
| Incidents | Ostensibly, a place to publicise errors and solutions | 2 July 2012 | The right place to publicise errors and solutions is a ticketing system. It may be the case that
certain obvious errors/pitfalls should be advertised in a clear manner elsewhere in documentation, e.g. site set-up instructions. In this case, the ticket should only be closed once the documentation change has also been made. In my opinion, it is not effective to declare errors and solutions here in this manner. The small number of contributions confirms this. Consider deleting this page. |
Deleted |
| PPS_sites_snapshot_-_July_2007 | PPS | 2 July 2012 | Useless | Deleted
|
