1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Grant Goodyear wrote: |
5 |
> Nathan L. Adams wrote: [Thu Nov 03 2005, 07:02:58PM CST] |
6 |
> |
7 |
>>-----BEGIN PGP SIGNED MESSAGE----- |
8 |
>>Hash: SHA1 |
9 |
>> |
10 |
>>Ciaran McCreesh wrote: |
11 |
>> |
12 |
>>>Read the list of requirements in the GLEP. The plain text solution |
13 |
>>>meets all of them. XML fails on several. |
14 |
>> |
15 |
>>If readability isn't a requirement, your list is wrong. |
16 |
> |
17 |
> |
18 |
> I would argue that reading raw xml is a lot less fun than reading minimally |
19 |
> marked-up plain text (such as an e-mail). |
20 |
|
21 |
Oh good grief! Nobody is arguing that the user should have to read raw XML. |
22 |
|
23 |
> |
24 |
>>>| So what are the trade-offs of the 'flat file'? If you store a |
25 |
>>>| migration guide as a 'flat file', its not going to be very readable. |
26 |
>>> |
27 |
>>>Who said anything about storing a migration guide as a flat file? Read |
28 |
>>>the GLEP. |
29 |
>> |
30 |
>>No, *you* need to read my previous response. I was using 'flat file' to |
31 |
>>mean whatever it is you're calling your less-than-GuideXML scheme. |
32 |
> |
33 |
> *Sigh* I think you might be misinterpreting the GLEP. The news items |
34 |
> are likely to be fairly short, such as the "YourSQL" example that's in |
35 |
> the GLEP. The news item would then point to a migration guide that |
36 |
> resides elsewhere, if needed. |
37 |
|
38 |
No, I happen to understand the that point. Emerge outputting a short |
39 |
summary is great. But the GLEP should cover the "hey mr. end user, the |
40 |
central repository for errata/full fledged migration guides is here: |
41 |
[insert url]" as well. |
42 |
|
43 |
> |
44 |
> The point behind having the news pulled by portage is that the headless |
45 |
> server, for example, would only report news items that are relevant to |
46 |
> that machine. The server's admin could then fire up a web browser on a |
47 |
> desktop machine to read any necessary additional info. |
48 |
|
49 |
Great; I'm not against that. Now where does that admin point her web |
50 |
browser? Mailing list archive? GWN archive? The Forums? The stated |
51 |
feedback is that users what a central place for the errata (whether the |
52 |
errata be large or small). |
53 |
|
54 |
> |
55 |
>>>| GuideXML is the standard for Gentoo docs for some damn good reasons! |
56 |
> |
57 |
> |
58 |
> True, but at the same time there's a reason that GLEPs can be written in |
59 |
> restructured text as well as guidexml. I doubt that it's accidental |
60 |
> that almost all GLEPs have been submitted in restructured text rather |
61 |
> than guidexml. (Incidentally, I like our guidexml. I think that it |
62 |
> renders quite well for what we want. I'm not so fond of writing it, |
63 |
> however.) |
64 |
> |
65 |
> That's really beside the point, though. The real point is that plain |
66 |
> text news items are going to be the easiest to create and the easiest to |
67 |
> read on a console screen. |
68 |
> |
69 |
> As for having an errata page, it wouldn't be difficult to write a |
70 |
> program to automatically convert news items to guidexml. I suspect that |
71 |
> ciaranm could even be talked into writing it, if such a page were to |
72 |
> become reality. |
73 |
|
74 |
I happen to think that the assumption that the errata are going to be |
75 |
small is a bad one. I think if errata is neccessary in the first place |
76 |
then its going to be something larger than a screen's worth of console |
77 |
output and worth the supposed trouble of GuideXML. So why not approach |
78 |
it from the GuideXML end first, and extract the summary from that? |
79 |
-----BEGIN PGP SIGNATURE----- |
80 |
Version: GnuPG v1.4.1 (GNU/Linux) |
81 |
|
82 |
iD8DBQFDavVI2QTTR4CNEQARAnMnAKCAir22mvnCgoKXc8xPDIYaQMmReACdELKr |
83 |
aa1l8avqCC7nIvV/VypyJj8= |
84 |
=LxgP |
85 |
-----END PGP SIGNATURE----- |
86 |
-- |
87 |
gentoo-dev@g.o mailing list |