1 |
Hey guys. I thought of something a couple of days ago. More of an |
2 |
evolutionary idea than a revolutionary one. So much so that I'm not sure |
3 |
if anyone's thought of it before -- perhaps there was some discussion a |
4 |
year or two ago when conditionals were first implemented, I don't recall. |
5 |
|
6 |
The idea is this: <include/>s. |
7 |
|
8 |
Simple, eh? We already do something vaguely related to this in the |
9 |
handbook-$arch.xml files. It's a sort of opposite and complementary |
10 |
approach to what we're already doing. Thing is, even in arch-specific |
11 |
handbook pages, there's a lot of identical stuff. However, there's also |
12 |
just enough different arch-specific stuff that we can't necessarily just |
13 |
lump them all into one common doc with keyval tests, at least, not |
14 |
without getting really muddy. |
15 |
|
16 |
So, step around the issue. Take partitioning and filesystems, for |
17 |
example. A lot of the explanatory text, paragraph after paragraph, is |
18 |
identical, or at least should be in all the docs. So, we use an |
19 |
<include/> to link that stuff in from another separate doc that holds |
20 |
that stuff. This way we don't have all the eggs in one basket. It gets |
21 |
easier to keep track of stuff. |
22 |
|
23 |
Easier to find the critical stuff that changes from release to release. |
24 |
I can see this also helping in post-release maintenance, as well; it's |
25 |
quicker to change code stuff, or add new explanatory <notes> or whatever |
26 |
that are good for all arches in the common external <include/> doc. |
27 |
|
28 |
We could even still use the existing conditional keyvals, too; nothing |
29 |
says those have to go away. |
30 |
|
31 |
It's too bad I didn't think of this sooner, as I would have liked to |
32 |
roll this out for this release. Also, it sounds like it might be rather |
33 |
complicated on the backend side, and that's another concern -- I don't |
34 |
think I have time for it, unless by some miracle I get all this stuff |
35 |
done in a week. Then I could spend a bit restructuring and figuring out |
36 |
common areas for the <include/>s -- if this happens at all, maybe we can |
37 |
do it to the handbooks *after* the release is out the door. |
38 |
|
39 |
So, thoughts? Comments? Concerns? Does it suck or has it been discussed |
40 |
and vetoed previously? Is it too complicated to implement, period? |
41 |
|
42 |
I think it's a good idea, and when I bounced it off JoseJX, he |
43 |
agreed...so that's two so far. Anyone else? |