On the website mtg today we discussed moving the redmine wiki content to the individual github wiki's. Matt mentioned we have the capability to mass migrate redmine pages to github wiki pages so we're asking each individual subcommunity which pages they would like to be migrated to their wiki.
The overall binding content will be moved to a combination of the conductor wiki and the aeolusproject.org github site wiki. The later isn't the best fit for the content (though alot of the content should go in the conductor wiki) but its the best option that we currently see atm.
We threw around the idea of a mediawiki installation but as Matt mentioned we previously had one (got littered with spam) and none of us felt the effort of setting one up was worth the cycles atm (can be revisited in the future). If anyone has any additional suggestions, feel free to shout out here.
We are looking at mid January as the cutoff date for this migration. We ask that a representative of each indivual subcommunity (deltacloud, imagefactory, oz, Tim, Heat, conductor, configure, aeolus-cli, and audrey) start looking at the redmine wiki and send us a list of the pages they want migrated. If you could send this to us by mid December that would be more than appreciated. Alternatively just migrate the wiki content you would like and just tell us (don't worry, we will find other things todo ;-) ).
We will keep the redmine wiki around after the end of January in read only mode for historical / archival purposes. Though at some point in the far future we most likely will shut it down for good.
-Mo
----- Original Message -----
From: "Mo Morsi" mmorsi@redhat.com To: "aeolus-devel" aeolus-devel@lists.fedorahosted.org Sent: Thursday, November 29, 2012 10:14:26 AM Subject: moving wiki content
On the website mtg today we discussed moving the redmine wiki content to the individual github wiki's. Matt mentioned we have the capability to mass migrate redmine pages to github wiki pages so we're asking each individual subcommunity which pages they would like to be migrated to their wiki.
The overall binding content will be moved to a combination of the conductor wiki and the aeolusproject.org github site wiki. The later isn't the best fit for the content (though alot of the content should go in the conductor wiki) but its the best option that we currently see atm.
We threw around the idea of a mediawiki installation but as Matt mentioned we previously had one (got littered with spam) and none of us felt the effort of setting one up was worth the cycles atm (can be revisited in the future). If anyone has any additional suggestions, feel free to shout out here.
We are looking at mid January as the cutoff date for this migration. We ask that a representative of each indivual subcommunity (deltacloud, imagefactory, oz, Tim, Heat, conductor, configure, aeolus-cli, and audrey) start looking at the redmine wiki and send us a list of the pages they want migrated. If you could send this to us by mid December that would be more than appreciated. Alternatively just migrate the wiki content you would like and just tell us (don't worry, we will find other things todo ;-) ).
We will keep the redmine wiki around after the end of January in read only mode for historical / archival purposes. Though at some point in the far future we most likely will shut it down for good.
-Mo
Hey Mo,
There are 15 pages in the audrey wiki. If it's easier, go ahead and migrate all the pages, and I'll clean it up after the migration (I have a list of about 7 pages that we'd likely keep around.
Also, it's worth pointing out that you could put the audrey wiki into read- only mode. That is, if it's possible to lock down certain projects' wikis without impacting other projects.
--- Greg
Hey Mo,
There are 15 pages in the audrey wiki. If it's easier, go ahead and migrate all the pages, and I'll clean it up after the migration (I have a list of about 7 pages that we'd likely keep around.
Also, it's worth pointing out that you could put the audrey wiki into read- only mode. That is, if it's possible to lock down certain projects' wikis without impacting other projects.
Greg
Hey Greg, good idea. We can use the Audrey wiki as sort of a trial run before the much bigger conductor wiki to see what this entails. And yes iirc, redmine wikis can be locked on a project by project basis.
Most likely the conductor wiki will be quite a bit more work as there is alot of content there that we need to exclude from the migration (else we'll be moving a jumbled mess over to the github wiki's) but this should give us a better guage of the migration process.
We'll be discussing this on the website mtg today, so stay tuned for more updates! Thanks for the feedback!
-Mo
On 12/06/2012 08:42 AM, Mo Morsi wrote:
Hey Mo,
There are 15 pages in the audrey wiki. If it's easier, go ahead and migrate all the pages, and I'll clean it up after the migration (I have a list of about 7 pages that we'd likely keep around.
Also, it's worth pointing out that you could put the audrey wiki into read- only mode. That is, if it's possible to lock down certain projects' wikis without impacting other projects.
Greg
Hey Greg, good idea. We can use the Audrey wiki as sort of a trial run before the much bigger conductor wiki to see what this entails. And yes iirc, redmine wikis can be locked on a project by project basis.
Most likely the conductor wiki will be quite a bit more work as there is alot of content there that we need to exclude from the migration (else we'll be moving a jumbled mess over to the github wiki's) but this should give us a better guage of the migration process.
We'll be discussing this on the website mtg today, so stay tuned for more updates! Thanks for the feedback!
-Mo
Hey Greg, migrated your wiki and tossed it up on my fedorapeople account (haven't used that in forever!). You can find the github compatible textile here:
http://mmorsi.fedorapeople.org/audrey-wiki.tgz
Take care, -Mo
On 12/06/2012 05:32 PM, Mo Morsi wrote:
On 12/06/2012 08:42 AM, Mo Morsi wrote:
Hey Mo,
There are 15 pages in the audrey wiki. If it's easier, go ahead and migrate all the pages, and I'll clean it up after the migration (I have a list of about 7 pages that we'd likely keep around.
Also, it's worth pointing out that you could put the audrey wiki into read- only mode. That is, if it's possible to lock down certain projects' wikis without impacting other projects.
Greg
Hey Greg, good idea. We can use the Audrey wiki as sort of a trial run before the much bigger conductor wiki to see what this entails. And yes iirc, redmine wikis can be locked on a project by project basis.
Most likely the conductor wiki will be quite a bit more work as there is alot of content there that we need to exclude from the migration (else we'll be moving a jumbled mess over to the github wiki's) but this should give us a better guage of the migration process.
We'll be discussing this on the website mtg today, so stay tuned for more updates! Thanks for the feedback!
-Mo
Hey Greg, migrated your wiki and tossed it up on my fedorapeople account (haven't used that in forever!). You can find the github compatible textile here:
http://mmorsi.fedorapeople.org/audrey-wiki.tgz
Take care, -Mo
Thanks Mo!
Joe
On 12/06/2012 05:32 PM, Mo Morsi wrote:
On 12/06/2012 08:42 AM, Mo Morsi wrote:
Hey Mo,
There are 15 pages in the audrey wiki. If it's easier, go ahead and migrate all the pages, and I'll clean it up after the migration (I have a list of about 7 pages that we'd likely keep around.
Also, it's worth pointing out that you could put the audrey wiki into read- only mode. That is, if it's possible to lock down certain projects' wikis without impacting other projects.
Greg
Hey Greg, good idea. We can use the Audrey wiki as sort of a trial run before the much bigger conductor wiki to see what this entails. And yes iirc, redmine wikis can be locked on a project by project basis.
Most likely the conductor wiki will be quite a bit more work as there is alot of content there that we need to exclude from the migration (else we'll be moving a jumbled mess over to the github wiki's) but this should give us a better guage of the migration process.
We'll be discussing this on the website mtg today, so stay tuned for more updates! Thanks for the feedback!
-Mo
Hey Greg, migrated your wiki and tossed it up on my fedorapeople account (haven't used that in forever!). You can find the github compatible textile here:
http://mmorsi.fedorapeople.org/audrey-wiki.tgz
Take care, -Mo
(D'oh! Meant to reply-list ... sorry)
Thanks Mo!
What's the plan now? I figured I'd just wait until it was up on github before messing with anything.
--- Greg
On 12/07/2012 10:04 AM, Greg Blomquist wrote:
On 12/06/2012 05:32 PM, Mo Morsi wrote:
On 12/06/2012 08:42 AM, Mo Morsi wrote:
Hey Mo,
There are 15 pages in the audrey wiki. If it's easier, go ahead and migrate all the pages, and I'll clean it up after the migration (I have a list of about 7 pages that we'd likely keep around.
Also, it's worth pointing out that you could put the audrey wiki into read- only mode. That is, if it's possible to lock down certain projects' wikis without impacting other projects.
Greg
Hey Greg, good idea. We can use the Audrey wiki as sort of a trial run before the much bigger conductor wiki to see what this entails. And yes iirc, redmine wikis can be locked on a project by project basis.
Most likely the conductor wiki will be quite a bit more work as there is alot of content there that we need to exclude from the migration (else we'll be moving a jumbled mess over to the github wiki's) but this should give us a better guage of the migration process.
We'll be discussing this on the website mtg today, so stay tuned for more updates! Thanks for the feedback!
-Mo
Hey Greg, migrated your wiki and tossed it up on my fedorapeople account (haven't used that in forever!). You can find the github compatible textile here:
http://mmorsi.fedorapeople.org/audrey-wiki.tgz
Take care, -Mo
(D'oh! Meant to reply-list ... sorry)
Thanks Mo!
What's the plan now? I figured I'd just wait until it was up on github before messing with anything.
Greg
The intro article from the github blog re: github wikis has some useful info about import/export[1].
m
[1] https://github.com/blog/699-making-github-more-open-git-backed-wikis
On 12/06/2012 05:32 PM, Mo Morsi wrote:
On 12/06/2012 08:42 AM, Mo Morsi wrote:
Hey Mo,
There are 15 pages in the audrey wiki. If it's easier, go ahead and migrate all the pages, and I'll clean it up after the migration (I have a list of about 7 pages that we'd likely keep around.
Also, it's worth pointing out that you could put the audrey wiki into read- only mode. That is, if it's possible to lock down certain projects' wikis without impacting other projects.
Greg
Hey Greg, good idea. We can use the Audrey wiki as sort of a trial run before the much bigger conductor wiki to see what this entails. And yes iirc, redmine wikis can be locked on a project by project basis.
Most likely the conductor wiki will be quite a bit more work as there is alot of content there that we need to exclude from the migration (else we'll be moving a jumbled mess over to the github wiki's) but this should give us a better guage of the migration process.
We'll be discussing this on the website mtg today, so stay tuned for more updates! Thanks for the feedback!
-Mo
Hey Greg, migrated your wiki and tossed it up on my fedorapeople account (haven't used that in forever!). You can find the github compatible textile here:
http://mmorsi.fedorapeople.org/audrey-wiki.tgz
Take care, -Mo
As a point of general information, when Matt and I ran through the process to see about feasibility we took the textile and ran it through pandoc[1] to convert it to markdown prior to pushing it into the github wiki. Every project is free to make their own decision on what format works best for them -- the underlying engine that github uses to render the wiki supports a fair number of lightweight markup languages[2].
Thanks, Mike
[1] http://johnmacfarlane.net/pandoc/ [2] https://github.com/github/gollum#readme
On Fri, Dec 07, 2012 at 10:15:14AM -0500, Mike Orazi wrote:
On 12/06/2012 05:32 PM, Mo Morsi wrote:
Hey Greg, migrated your wiki and tossed it up on my fedorapeople account (haven't used that in forever!). You can find the github compatible textile here:
While I think this approach is perfectly fine, just in terms of semantics for future migrations, I'd say that the "migration" includes putting the content up on GitHub. This feels more like an export than a migration.
As a point of general information, when Matt and I ran through the process to see about feasibility we took the textile and ran it through pandoc[1] to convert it to markdown prior to pushing it into the github wiki. Every project is free to make their own decision on what format works best for them -- the underlying engine that github uses to render the wiki supports a fair number of lightweight markup languages[2].
<snip>
[1] http://johnmacfarlane.net/pandoc/ [2] https://github.com/github/gollum#readme
Yes, when I did an experimental migration from Redmine to GitHub for the Conductor wiki (on my fork of the project), I used Pandoc to convert everything to Markdown.
The GitHub wiki will merrily work with either format (and some others), but when you create a page in one format, it stays in that format. Since Markdown seems a lot more popular (and, IMHO, sane) than Textile, I thought it made sense to bulk-convert everything as well.
So I'd say the flow should be export from Redmine -> pandoc -> import to GitHub as Markdown.
-- Matt
----- Original Message -----
From: "Matt Wagner" matt.wagner@redhat.com To: "Mike Orazi" morazi@redhat.com Cc: aeolus-devel@lists.fedorahosted.org Sent: Monday, December 10, 2012 10:33:19 AM Subject: Re: moving wiki content
On Fri, Dec 07, 2012 at 10:15:14AM -0500, Mike Orazi wrote:
On 12/06/2012 05:32 PM, Mo Morsi wrote:
Hey Greg, migrated your wiki and tossed it up on my fedorapeople account (haven't used that in forever!). You can find the github compatible textile here:
While I think this approach is perfectly fine, just in terms of semantics for future migrations, I'd say that the "migration" includes putting the content up on GitHub. This feels more like an export than a migration.
Hey Matt,
it's actually on github also: https://github.com/aeolusproject/audrey/wiki/_pages
That may have been just an intermediate step between publishing to github.
As a point of general information, when Matt and I ran through the process to see about feasibility we took the textile and ran it through pandoc[1] to convert it to markdown prior to pushing it into the github wiki. Every project is free to make their own decision on what format works best for them -- the underlying engine that github uses to render the wiki supports a fair number of lightweight markup languages[2].
<snip> > [1] http://johnmacfarlane.net/pandoc/ > [2] https://github.com/github/gollum#readme
Yes, when I did an experimental migration from Redmine to GitHub for the Conductor wiki (on my fork of the project), I used Pandoc to convert everything to Markdown.
The GitHub wiki will merrily work with either format (and some others), but when you create a page in one format, it stays in that format. Since Markdown seems a lot more popular (and, IMHO, sane) than Textile, I thought it made sense to bulk-convert everything as well.
So I'd say the flow should be export from Redmine -> pandoc -> import to GitHub as Markdown.
-- Matt
On 11/29/2012 07:14 AM, Mo Morsi wrote:
On the website mtg today we discussed moving the redmine wiki content to the individual github wiki's. Matt mentioned we have the capability to mass migrate redmine pages to github wiki pages so we're asking each individual subcommunity which pages they would like to be migrated to their wiki.
The overall binding content will be moved to a combination of the conductor wiki and the aeolusproject.org github site wiki. The later isn't the best fit for the content (though alot of the content should go in the conductor wiki) but its the best option that we currently see atm.
We threw around the idea of a mediawiki installation but as Matt mentioned we previously had one (got littered with spam) and none of us felt the effort of setting one up was worth the cycles atm (can be revisited in the future). If anyone has any additional suggestions, feel free to shout out here.
We are looking at mid January as the cutoff date for this migration. We ask that a representative of each indivual subcommunity (deltacloud, imagefactory, oz, Tim, Heat, conductor, configure, aeolus-cli, and audrey) start looking at the redmine wiki and send us a list of the pages they want migrated. If you could send this to us by mid December that would be more than appreciated. Alternatively just migrate the wiki content you would like and just tell us (don't worry, we will find other things todo ;-) ).
We will keep the redmine wiki around after the end of January in read only mode for historical / archival purposes. Though at some point in the far future we most likely will shut it down for good.
-Mo
Regarding aeolus-cli, there are no redmine pages I am aware of that need to be migrated.
Unrleated to redmine, we probably want to update the aeolus-cli README and/or aeolus-cli github wiki to: *Mention that it will be replaced by thor-cli where upstream development is taking place. *Include links to the useful set of web pages beginning with http://www.aeolusproject.org/gsg/0.10.0/configure_cli.html
--Crag
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: 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 GitHub_Branches_and_Tags <./GitHub_Branches_and_Tags.html> 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
to conductor wiki: API_Style_Guide Catalogs Cloud_State Common_Error_Messages Code_Repository_and_Commits Conductor Completed_Security_Tasks ConductorAPIResourceRepresentation ConductorAPIv1_0 <./ConductorAPIv1_0.html> 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)
excluding: (Most of these are feature pages, alot of these are done or no longer apply) *Sprint* 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 Command_Line_Interface_commands Condor_Removal Completed_Publicity_Cabal_Agenda_Items Conductor 2012* (not sure what these are) ConductorAPI <./ConductorAPI.html> 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 Document_Conductor_models_and_relationships <./Document_Conductor_models_and_relationships.html> 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 V2 Conductor* Wiki
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
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.
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
- 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
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_iwhdI 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_consoleI'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* WikiThis appears to be the main page. Are we just going to rename it?
References
Visible links 1. GitHub_Branches_and_Tagsfile:///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
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.
-1 this isn't the plan we agreed upon before I started working on this.
We had explicitly wanted to split the content up, between the umbrella (Aeolus), the all-in-one solution (conductor), and the other wikis.
We had discussed alternatives to using the site wiki, but the only one we came up with was using a mediawiki instance. We didn't want to do this since the last mediawiki instance we instance was littered with spam, though in retrospect I'm sure we could have found a way to deal w/ that.
I am willing to compromise. If anyone insists on not using the site wiki, I'll do the export, generating tarballs with the content separated in the manner I described below, and hand them off to whoever wants to take it from there.
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'm fine w/ the first one being on the conductor wiki.
excluding: (Most of these are feature pages, alot of these are done or no longer apply) *Sprint*
Is there historic value in these?
Again the original plan was to _not_ delete anything off the old wiki, just lock it down.
Everything being migrated and everything excluded will still be available there in read-only mode.
At some point in the far future (lets say 6 months from now) we can look at whether or not we want to take redmine down for good.
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.
Same comment as above. Unless there is a specific reason not to exclude it (eg 'we need xyz because ...') we can leave it on the old read-only wiki until someone needs it (and then they can move it to wherever they want themselves ;-) ).
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.
This is fine, will move this to the conductor wiki.
V2 Conductor* Wiki
This appears to be the main page. Are we just going to rename it?
There are actually many pages that contain this same content. Not really sure why we have several copies.
Thanks for putting this together, Mo. Seems like we had an awful lot of stuff on the wiki!
Hence the mid-to-end of January timeline! ;-) (which now is seeming a little tight in itself)
-Mo
On Wed, Dec 19, 2012 at 07:10:35AM -0500, Mo Morsi wrote:
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.
-1 this isn't the plan we agreed upon before I started working on this.
We had explicitly wanted to split the content up, between the umbrella (Aeolus), the all-in-one solution (conductor), and the other wikis.
We had discussed alternatives to using the site wiki, but the only one we came up with was using a mediawiki instance. We didn't want to do this since the last mediawiki instance we instance was littered with spam, though in retrospect I'm sure we could have found a way to deal w/ that.
Ah, okay. I remember that discussion, though I forgot we decided to use the site wiki. In any event, I don't have a better suggestion. (It also looks like the Tech Cabal has been keeping notes there already, so there's a precedent for its use.)
I am willing to compromise. If anyone insists on not using the site wiki, I'll do the export, generating tarballs with the content separated in the manner I described below, and hand them off to whoever wants to take it from there.
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'm fine w/ the first one being on the conductor wiki.
excluding: (Most of these are feature pages, alot of these are done or no longer apply) *Sprint*
Is there historic value in these?
Again the original plan was to _not_ delete anything off the old wiki, just lock it down.
Sorry, my memory must be going...
Everything being migrated and everything excluded will still be available there in read-only mode.
At some point in the far future (lets say 6 months from now) we can look at whether or not we want to take redmine down for good.
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.
Same comment as above. Unless there is a specific reason not to exclude it (eg 'we need xyz because ...') we can leave it on the old read-only wiki until someone needs it (and then they can move it to wherever they want themselves ;-) ).
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.
This is fine, will move this to the conductor wiki.
V2 Conductor* Wiki
This appears to be the main page. Are we just going to rename it?
There are actually many pages that contain this same content. Not really sure why we have several copies.
Odd...
Thanks for putting this together, Mo. Seems like we had an awful lot of stuff on the wiki!
Hence the mid-to-end of January timeline! ;-) (which now is seeming a little tight in itself)
-Mo
Okay, sorry for my apparent memory lapses. I didn't mean to contradict what had already been decided, and I didn't realize the plan was to keep the old wiki read-only. That eliminates most of my concerns!
-- Matt
On 12/17/2012 10:44 AM, 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
OK did the export and conversion and am beginning the arduous process of importing the pages on github. The conversion isn't 100% perfect so this will take some time to clean things up as they are moved over. That being said, I'm still targeting the end of this month as the final cut over date.
I ask the team to use github as much as possible from here on out, while I won't lock down redmine just yet, alot of edits there will exponentially increase my workload.
If you absolutely must edit redmine, I ask that you try to keep track of what you changed so that it makes the final cleanup all the easier.
Thanks, -Mo
On Thu, Jan 03, 2013 at 04:40:51PM -0500, Mo Morsi wrote:
On 12/17/2012 10:44 AM, 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. -MoOK did the export and conversion and am beginning the arduous process of importing the pages on github. The conversion isn't 100% perfect so this will take some time to clean things up as they are moved over. That being said, I'm still targeting the end of this month as the final cut over date.
Couldn't we just clone the Gollum wiki, dump the converted pages in, and push them up? That way we get something in place quickly, and, more importantly, you can try to get others to help you clean up the bits the conversion didn't tackle. O:-)
-- Matt
On Fri, Jan 04, 2013 at 11:44:21AM -0500, Matt Wagner wrote:
On Thu, Jan 03, 2013 at 04:40:51PM -0500, Mo Morsi wrote:
On 12/17/2012 10:44 AM, 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. -MoOK did the export and conversion and am beginning the arduous process of importing the pages on github. The conversion isn't 100% perfect so this will take some time to clean things up as they are moved over. That being said, I'm still targeting the end of this month as the final cut over date.
Couldn't we just clone the Gollum wiki, dump the converted pages in, and push them up? That way we get something in place quickly, and, more importantly, you can try to get others to help you clean up the bits the conversion didn't tackle. O:-)
Yeah, I don't understand why we're not following the get-it-done path here.
--Hugh
On 01/05/2013 06:40 AM, Hugh Brock wrote:
On Fri, Jan 04, 2013 at 11:44:21AM -0500, Matt Wagner wrote:
On Thu, Jan 03, 2013 at 04:40:51PM -0500, Mo Morsi wrote:
On 12/17/2012 10:44 AM, 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. -MoOK did the export and conversion and am beginning the arduous process of importing the pages on github. The conversion isn't 100% perfect so this will take some time to clean things up as they are moved over. That being said, I'm still targeting the end of this month as the final cut over date.
Couldn't we just clone the Gollum wiki, dump the converted pages in, and push them up? That way we get something in place quickly, and, more importantly, you can try to get others to help you clean up the bits the conversion didn't tackle. O:-)
Yeah, I don't understand why we're not following the get-it-done path here.
--Hugh
Just didn't know about the gollum wiki. In any case, imported the site wiki last week and am working on cleaning that up now.
-Mo
On 01/07/2013 08:22 AM, Mo Morsi wrote:
On 01/05/2013 06:40 AM, Hugh Brock wrote:
On Fri, Jan 04, 2013 at 11:44:21AM -0500, Matt Wagner wrote:
On Thu, Jan 03, 2013 at 04:40:51PM -0500, Mo Morsi wrote:
On 12/17/2012 10:44 AM, 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. -MoOK did the export and conversion and am beginning the arduous process of importing the pages on github. The conversion isn't 100% perfect so this will take some time to clean things up as they are moved over. That being said, I'm still targeting the end of this month as the final cut over date.
Couldn't we just clone the Gollum wiki, dump the converted pages in, and push them up? That way we get something in place quickly, and, more importantly, you can try to get others to help you clean up the bits the conversion didn't tackle. O:-)
Yeah, I don't understand why we're not following the get-it-done path here.
--Hugh
Just didn't know about the gollum wiki. In any case, imported the site wiki last week and am working on cleaning that up now.
-Mo
The majority of the stuff on the site wiki is done. There are some small things here and there, but we can take care of things as we go along (when editing pages, just keep an eye out for things that look off).
Next up is the conductor wiki (imported this and started the formatting yesterday).
-Mo
On 01/10/2013 08:23 AM, Mo Morsi wrote:
The majority of the stuff on the site wiki is done. There are some small things here and there, but we can take care of things as we go along (when editing pages, just keep an eye out for things that look off).
Next up is the conductor wiki (imported this and started the formatting yesterday).
-Mo
The site wiki is done and the majority of content on the Conductor wiki is as well. Conductor should be done by the end of the week.
Redmine is now locked down so people should now be putting content on the github wiki's, preferable the wiki for the project which the content relates to (would like to keep the site wiki as clean as possible).
The redmine wiki will remain in read only mode for now, though in the June/July timeframe we'll evaluate whether or not our redmine instance can be shutdown for good.
-Mo
Hey I'm gonna be wrapping this up sometime next week so if you need something off redmine [1] grab it now.
I'll take a final snapshot of the vm and db and store them on a cd before deleting both from the live systems.
-Mo
[1] https://redmine.aeolusproject.org/redmine
-------- Original Message -------- Subject: Re: moving wiki content Date: Tue, 15 Jan 2013 18:32:43 -0500 From: Mo Morsi mmorsi@redhat.com To: aeolus-devel aeolus-devel@lists.fedorahosted.org
On 01/10/2013 08:23 AM, Mo Morsi wrote:
The majority of the stuff on the site wiki is done. There are some small things here and there, but we can take care of things as we go along (when editing pages, just keep an eye out for things that look off).
Next up is the conductor wiki (imported this and started the formatting yesterday).
-Mo
The site wiki is done and the majority of content on the Conductor wiki is as well. Conductor should be done by the end of the week.
Redmine is now locked down so people should now be putting content on the github wiki's, preferable the wiki for the project which the content relates to (would like to keep the site wiki as clean as possible).
The redmine wiki will remain in read only mode for now, though in the June/July timeframe we'll evaluate whether or not our redmine instance can be shutdown for good.
-Mo
aeolus-devel@lists.fedorahosted.org
-
cwolferh -
Greg Blomquist -
Hugh O. Brock -
Joseph VLcek -
Matt Wagner -
Mike Orazi -
Mo Morsi