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