1 |
On 09/11/2017 01:56 PM, Michał Górny wrote: |
2 |
> W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael |
3 |
> Orlitzky napisał: |
4 |
>> On 09/11/2017 01:08 PM, Michał Górny wrote: |
5 |
>>> Hi, |
6 |
>>> |
7 |
>>> TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather |
8 |
>>> than Wiki, put in a nice git repo. |
9 |
>>> |
10 |
>> |
11 |
>> I generally agree with you that wiki markup is terrible and that a text |
12 |
>> editor and a git repo is The Right Way to do things (with Jekyll or |
13 |
>> whatever to push it to the web). But in my experience, crappy and easy |
14 |
>> is a better way to get people to contribute. When I've taken wiki |
15 |
>> documents and moved them into git repos, more often than not I become |
16 |
>> the sole contributor, and otherwise-technical people just start emailing |
17 |
>> me their contributions (which decrease greatly in frequency). |
18 |
> |
19 |
> Rich already answered this in detail, so I'll skip it. |
20 |
> |
21 |
>> Will it be possible to build the GLEP rst files locally, and view the |
22 |
>> output exactly as it would appear on the website? I ask because, so long |
23 |
>> as you don't want to be able to preview the result, you can already |
24 |
>> write MediaWiki markup into a text file locally. The offline "live |
25 |
>> preview" ability is the killer feature of RST as I see it. |
26 |
> |
27 |
> Of course yes. However, the exactness of result depends on how much |
28 |
> effort you put into it. |
29 |
> |
30 |
> The 'easy way' is rst2html.py (dev-python/docutils). It will give you |
31 |
> a rough rendering with a standard style, i.e. kinda ugly but enough to |
32 |
> see if everything works as expected. You'll also see the preamble as big |
33 |
> mumbo-jumbo on top. |
34 |
> |
35 |
> Then, there's glep.py (dev-python/docutils-glep) which adds preamble |
36 |
> parsing, table of contents and some styling. AFAICS it needs a bit |
37 |
> handiwork (copying a stylesheet to a relative directory) but it gives |
38 |
> nice old-school rendering. |
39 |
> |
40 |
> Then, you can just take www.gentoo.org and run it locally. It takes |
41 |
> a little more effort but jekyll is really trivial to set up and run |
42 |
> locally. Then you see it exactly how it's gonna look on g.o. |
43 |
> |
44 |
> As a side note, we may also rename GLEPs to .rst. Then, GitHub will also |
45 |
> provide out-of-the-box rendering of them. |
46 |
> |
47 |
To preface, I really like the idea to do this in Git. Much as I |
48 |
appreciate what the wiki team has done, collaboration isn't quite as |
49 |
smooth on it and as another person mentioned, it's hard to get reviews, |
50 |
so you get to choose to leave something in your userspace (I liked your |
51 |
Drafts namespace idea, fwiw) or edit a page anyway and hope for the best. |
52 |
|
53 |
That said... Is it wise to rely on Ruby (via Jekyll) for critical |
54 |
reference documents, given how often minor version bumps in Ruby disrupt |
55 |
its ecosystem? Do we really need the entire www.gentoo.org repository in |
56 |
order to view and hack on GLEPs? I see little reason for GLEPs to not be |
57 |
in their own repository, depending on something more stable than Jekyll |
58 |
and Ruby. Given that the doc tools themselves are written in Python, it |
59 |
makes more sense (imo) to leverage Gentoo's existing technical |
60 |
investment in Python and use something like app-text/pelican, which is |
61 |
equally, if not more capable than Jekyll and will not require pulling in |
62 |
Ruby just to hack on and preview some text. Every Gentoo system comes |
63 |
with Python unless you go off the beaten path and know what you're |
64 |
doing, so that's a bonus, too. |
65 |
|
66 |
Of course, this changes if we need some extremely advanced behavior. I'm |
67 |
not sure how easy it is to build a Pelican plugin, but there's an entire |
68 |
repo full of them. [1] Pelican also uses a Makefile you can hack on |
69 |
(even multiple publishing targets), and supports GNU gettext for |
70 |
translations. |
71 |
|
72 |
Or is Jekyll chosen purely because the current website is built with it? |
73 |
In that case, it at least makes sense despite the heavyweight dependencies. |
74 |
|
75 |
If anyone's interested in seeing a mockup of a few GLEPs in Pelican, I |
76 |
can get that started. |
77 |
|
78 |
Whether or not the structure works on GitHub is orthogonal to the |
79 |
decision. Still, put me down in favor of switching to Git. Thanks for |
80 |
putting together the proposal. |
81 |
|
82 |
[1]: https://github.com/getpelican/pelican-plugins |
83 |
-- |
84 |
Daniel Campbell - Gentoo Developer, Trustee, Treasurer |
85 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
86 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |