On 12/17/2012 03:22 PM, Matt Wagner wrote:
On Mon, Dec 17, 2012 at 10:44:54AM -0500, Mo Morsi wrote:
The following is the list of wiki pages grouped by their ultimate
destination. If there are any errors please reply here. I'll start the
migration process this week.
Still need to figure out how to handle images and files that have been
uploaded and links to other wiki pages.
-Mo
-----------------------------
to site wiki:
We never found a better place, though the website's wiki feels like an
odd spot. I'd almost be up for just putting these on the Conductor wiki,
since it's sort of been a de facto location for stuff that's
cross-project.
Aeolus_Components
Aeolus_Demo_Setup
Aeolus_Demo_Commands
Blockers
Blogaeolusprojectorg_playbook
Competitor_Analysis
Coding_Guidelines
Continuous_Integration_Testing
Etherpad_playbook
Feature_Template_Page
General_Development_Process
Git_Branching_Strategy
Git_Commit_Access_Policy
[1]GitHub_Branches_and_Tags
Git_Workflow
Packaging
Patch_Reviews_and_Commits
Personas
Presentations
Publicity_Cabal
Release_Cabal
Release_Checklist
Release_Process
RHEV-M_Setup
Setting_up_Openstack
Setting_up_oVirt
Upgrading_Aeolus
Using_the_RHEV-M_API
VSphere_Setup
Website_Cabal
Website_Revamp_Project
X-Deltacloud-Provider
There are a few things on this list that fall into the dated category,
but I agree with matty_dubs -- it is probably better to move them as-is
and enter issues to either update or remove the offending content. In
particular, I'm thinking:
Git_Branching_Strategy
Release_Checklist
Website_Revamp_Project
In terms of additions, I think it would be useful to keep the Publicity
Cabal Minutes where we keep the Publicity_Cabal writeup.
to conductor wiki:
API_Style_Guide
Catalogs
Cloud_State
Common_Error_Messages
Code_Repository_and_Commits
Conductor
Completed_Security_Tasks
ConductorAPIResourceRepresentation
[2]ConductorAPIv1_0
Conductor_Audit_and_Update
Conductor_Deployable_Template_Stories
Conductor_Image_Management_API_design
Conductor_on_OSX
Conductor_UI_Style_Guide
Debugging_Conductor_(production)
Deployable_Deployment_and_Instance_API
Deployables
Deployable_XML
Deployments
Forms
Glossary_of_Terms
Hardening_conductor_entry_points
Hardening_Conductor_models
Hardening_the_app
Image_Building_CLI
Implementing_New_Providers
Implementing_OpenStack_support
Infrastructure_Security_Needs
Instance_and_provider_states
Instances
Internationalization
Launching_Instances
Launch_requests_blocking_on_approval
LDAP_Support
List_of_log_files
List_of_UI_Annoyances
Model_Arch_Diagrams
Mustache_templates
Notification_System
OAuth
OAuth_-_Conductor_and_ConfigServer
Pool_Families
Pools
Provider_Accounts
Providers
Provider_Selection_Algorithms
Provider_Types
Realm_Mappings
Realms_-_Front_End
Realms_-_Provider
Renaming_All_the_Components
Roles_and_Permissions
Roles_list
Scheduleddelayed_launch_and_maximum_execution_time
Support_complex_provider_selection_algorithms
Upstream_and_Product_Name_Cheatsheet
Using_Audrey_with_Conductor
to other wikis:
Building_Images_for_RHEL (imagefactory, oz)
Development_Setup (imagefactory, oz)
Image_Management_Engine (tim)
Oz_template_description_language (oz)
Not to complicate things, but some of these (such as the 'Building
Images for RHEL' page) were things meant to be how-to guides for
Conductor users, IIRC. It's interesting to me that there are only four
pages that don't fall into the project-wide or Conductor categories so
far -- it almost makes me wonder if we should just lump everything under
one wiki.
I have similar feelings on this but I think I'd rather see things out of
redmine vs extending the discussion on the theory that it is easier to
move stuff around after the fact (and maintain a record of
addition/removal as well).
excluding: (Most of these are feature pages, alot of these are done or no
longer apply)
*Sprint*
Is there historic value in these?
Adding_Caching_to_Conductor
Adding_Permission_Grant_list_to_UserGroup_Profile_UI
Add_Targeted_Reports_and_Statistical_Data
Adding_User_Groups
Aeolus-configure
Aeolus_vs_OpenStack
Aeolus_User_Stories
Aeolus_uninstall
Allow_Conductor_to_keep_a_history_of_deployment_activity
All_provider_config_to_reside_in_Conductor
Auto_Scaling
Background_Processing
Clearing_iwhd
I was looking for this page just the other day, trying to help someone
with a messed-up 1.0 install. I expect this is quite uncommon, but it
kind of makes me wonder if there's more value than meets the eye in
keeping some of these pages around.
Command_Line_Interface_commands
Condor_Removal
Completed_Publicity_Cabal_Agenda_Items
Conductor 2012* (not sure what these are)
[3]ConductorAPI
Conductor_API_v_1
Consistent_forms_in_Conductor_UI
Current_Release_Patches_Needed
Dbomatic_testability_and_performance
Design_the_model_changes_for_support_of_stateful_instances
Detailed_architecture_of_the_Conductor_UI
Documentation_Plan
Document_Conductor_developer_setup
[4]Document_Conductor_models_and_relationships
[5]Feature*
Frequently_Asked_Questions (not much here)
Git_Inside
I4_S4_Infra_Planning
I4_S5_Infra_Planning
ICICLE (?)
Image_BuildPush
Imagefactory_API__Conductor_Work
Image_Models
IME_Conductor_Integration
Infra*Sprint*
In_Development
Infrastructure_Projects
Iteration*Sprint*
Integration_Environment_+_Automated_Tests
Known_limitations
Launching_deployments_with_interdependent_instances
Moving_Redmine_to_OpenShift
Multimachine_aeolus-configure
Next-generation_Testing_Brainstorm
Next_Sprint_Candidates_(Infra)
Next_Sprint_Candidates_(QEAutomation)
P*-s*
Optimize_Hardware_Matching
Other_Components_Security
OVirt_Setup (empty)
Pacemaker_Cloud_and_Conductor_Notification_API
Pages_to_migrate
Permission_record_denormalization
Plugins_In_Use
Plugins_Of_Interest
Publicity cabal minutes*
Portlets
Proposed_Wiki_Reorg
Public_Redmine
Rails3_Upgrade
Rails_best_practices_output (all but empty)
Rationalise_Conductor's_UI_code
Redmine*
Reduce_or_Eliminate_Conductor_Remote_Calls_to_Image_Warehouse
Robust_instance_launching
RPM_diff_between_master_and_product
Shared_UI_with_Katello
SocialNetworks
Sprint*
Syslog_Libraries
Testing_DMA
Testing_holy_grail
Upcoming_Topics
Using_the_Rails_console
I'd put this together a while back to help less-technical people. I'm
not sure anyone has used it in a while, though it may still have value.
V2 Conductor*
Wiki
This appears to be the main page. Are we just going to rename it?
References
Visible links
1. GitHub_Branches_and_Tags
file:///tmp/GitHub_Branches_and_Tags.html
2. ConductorAPIv1_0
file:///tmp/ConductorAPIv1_0.html
3. ConductorAPI
file:///tmp/ConductorAPI.html
4. Document_Conductor_models_and_relationships
file:///tmp/Document_Conductor_models_and_relationships.html
5. Feature*
file:///tmp/
Thanks for putting this together, Mo. Seems like we had an awful lot of
stuff on the wiki!
I noted a handful of stuff that I'm not sure we need to delete; every
now and then it's useful to be able to go back and look at old sprint
documents or whatnot. (Case in point, I recently had to help someone
pull a design doc off of the old Mediawiki site.) In general I'd
advocate keeping anything that isn't misleading and wrong, and doesn't
make sense to update. Overall, I think this gets us fairly close,
though. (We can always delete pages _after_ the migration, too -- and in
fact they'll enter git history that way. Hence my thinking that it makes
sense to be quite conservative with what we delete.)
-- Matt
Thanks Mo!
I added a few to the potentially ignore pile but I'd readily agree with
Matt in that it might be better to do some amount of pruning
post-migration. I am not opposed to pruning the obviously irrelevant
stuff like:
Conductor 2012*
The other bit wasn't explicitly mentioned so I thought I would ask. I
think the general consensus was that we should convert the textile to
markdown prior to importing the pages into github. I haven't heard any
dissenting views, but maybe it is worthwhile to explicitly say unless we
hear disagreement on the list by Wednesday 5:00 pm EST everything will
get run through pandoc and be imported as markdown.
Thanks,
Mike
