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