RE: Breaking docs out
The docs for 4.2 are not settled yet and may take another couple of days. David are you considering the change for 4.2? -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, August 07, 2013 12:11 AM To: dev Subject: Re: Breaking docs out ok, +0 then, I'm off for a coffee. On Tue, Aug 6, 2013 at 10:21 PM, Jessica Tomechak jessica.tomec...@citrix.com wrote: I'm +0 on it. Don't really mind either way. Jessica T. From: Radhika Puthiyetath [radhika.puthiyet...@citrix.com] Sent: Monday, August 05, 2013 9:25 PM To: dev@cloudstack.apache.org Subject: RE: Breaking docs out Make perfect sense. + 1 -Radhika -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, August 06, 2013 3:13 AM To: dev@cloudstack.apache.org Subject: Breaking docs out Hi folks: I'd like to propose breaking out a nuymber of our documents into their own repos. My thinking is that specifically; the release notes, midonet, and niciranvp documentation shares very little with the rest of the documentation, and should be broken out akin to how the QIG is currently broken out. The particular problem I am trying to solve is to deal with publishing. For instance, even though the release notes are contained in just a few xml documents, it copies content from every single xml file in thd directory - over 400 - and it also copies those up to the website. Splitting things up also allows us to prioritize l10n. Right now, we just dump 400 xml files worth of content into transifex and people translate away - they can't put a priority on release notes, or de- emphasize more esoteric documentation like Nicira or Midonet. Eventually I'd like to break out each of the individual guides into their own document - separate from the other. Right now they carry a ton of similar content so that isn't very practical; but it's what I am thinking, perhaps for 4.4 or 4.5. In the meantime, I'd like to make this change as soon as we think we have documentation pretty close to done for 4.2 to minimize the disruptive effects. Thoughts, comments, flames? --David
Re: Breaking docs out
ok, +0 then, I'm off for a coffee. On Tue, Aug 6, 2013 at 10:21 PM, Jessica Tomechak jessica.tomec...@citrix.com wrote: I'm +0 on it. Don't really mind either way. Jessica T. From: Radhika Puthiyetath [radhika.puthiyet...@citrix.com] Sent: Monday, August 05, 2013 9:25 PM To: dev@cloudstack.apache.org Subject: RE: Breaking docs out Make perfect sense. + 1 -Radhika -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, August 06, 2013 3:13 AM To: dev@cloudstack.apache.org Subject: Breaking docs out Hi folks: I'd like to propose breaking out a nuymber of our documents into their own repos. My thinking is that specifically; the release notes, midonet, and niciranvp documentation shares very little with the rest of the documentation, and should be broken out akin to how the QIG is currently broken out. The particular problem I am trying to solve is to deal with publishing. For instance, even though the release notes are contained in just a few xml documents, it copies content from every single xml file in thd directory - over 400 - and it also copies those up to the website. Splitting things up also allows us to prioritize l10n. Right now, we just dump 400 xml files worth of content into transifex and people translate away - they can't put a priority on release notes, or de-emphasize more esoteric documentation like Nicira or Midonet. Eventually I'd like to break out each of the individual guides into their own document - separate from the other. Right now they carry a ton of similar content so that isn't very practical; but it's what I am thinking, perhaps for 4.4 or 4.5. In the meantime, I'd like to make this change as soon as we think we have documentation pretty close to done for 4.2 to minimize the disruptive effects. Thoughts, comments, flames? --David
Re: Breaking docs out
one litle spark here; why does every thing need to go in its own repo. I would rather go for putting it all in one repo. not much of a flame but here you go. Daan On Tue, Aug 6, 2013 at 6:25 AM, Radhika Puthiyetath radhika.puthiyet...@citrix.com wrote: Make perfect sense. + 1 -Radhika -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, August 06, 2013 3:13 AM To: dev@cloudstack.apache.org Subject: Breaking docs out Hi folks: I'd like to propose breaking out a nuymber of our documents into their own repos. My thinking is that specifically; the release notes, midonet, and niciranvp documentation shares very little with the rest of the documentation, and should be broken out akin to how the QIG is currently broken out. The particular problem I am trying to solve is to deal with publishing. For instance, even though the release notes are contained in just a few xml documents, it copies content from every single xml file in thd directory - over 400 - and it also copies those up to the website. Splitting things up also allows us to prioritize l10n. Right now, we just dump 400 xml files worth of content into transifex and people translate away - they can't put a priority on release notes, or de-emphasize more esoteric documentation like Nicira or Midonet. Eventually I'd like to break out each of the individual guides into their own document - separate from the other. Right now they carry a ton of similar content so that isn't very practical; but it's what I am thinking, perhaps for 4.4 or 4.5. In the meantime, I'd like to make this change as soon as we think we have documentation pretty close to done for 4.2 to minimize the disruptive effects. Thoughts, comments, flames? --David
Breaking docs out
Hi folks: I'd like to propose breaking out a nuymber of our documents into their own repos. My thinking is that specifically; the release notes, midonet, and niciranvp documentation shares very little with the rest of the documentation, and should be broken out akin to how the QIG is currently broken out. The particular problem I am trying to solve is to deal with publishing. For instance, even though the release notes are contained in just a few xml documents, it copies content from every single xml file in thd directory - over 400 - and it also copies those up to the website. Splitting things up also allows us to prioritize l10n. Right now, we just dump 400 xml files worth of content into transifex and people translate away - they can't put a priority on release notes, or de-emphasize more esoteric documentation like Nicira or Midonet. Eventually I'd like to break out each of the individual guides into their own document - separate from the other. Right now they carry a ton of similar content so that isn't very practical; but it's what I am thinking, perhaps for 4.4 or 4.5. In the meantime, I'd like to make this change as soon as we think we have documentation pretty close to done for 4.2 to minimize the disruptive effects. Thoughts, comments, flames? --David
RE: Breaking docs out
Make perfect sense. + 1 -Radhika -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, August 06, 2013 3:13 AM To: dev@cloudstack.apache.org Subject: Breaking docs out Hi folks: I'd like to propose breaking out a nuymber of our documents into their own repos. My thinking is that specifically; the release notes, midonet, and niciranvp documentation shares very little with the rest of the documentation, and should be broken out akin to how the QIG is currently broken out. The particular problem I am trying to solve is to deal with publishing. For instance, even though the release notes are contained in just a few xml documents, it copies content from every single xml file in thd directory - over 400 - and it also copies those up to the website. Splitting things up also allows us to prioritize l10n. Right now, we just dump 400 xml files worth of content into transifex and people translate away - they can't put a priority on release notes, or de-emphasize more esoteric documentation like Nicira or Midonet. Eventually I'd like to break out each of the individual guides into their own document - separate from the other. Right now they carry a ton of similar content so that isn't very practical; but it's what I am thinking, perhaps for 4.4 or 4.5. In the meantime, I'd like to make this change as soon as we think we have documentation pretty close to done for 4.2 to minimize the disruptive effects. Thoughts, comments, flames? --David
