Gentoo Archives: gentoo-dev

From: Daniel Campbell <zlg@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan
Date: Tue, 12 Sep 2017 07:08:18
Message-Id: 82c03c0d-7991-1665-83a1-d9b4d1187643@gentoo.org
In Reply to: Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan by "Michał Górny"
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan "Michał Górny" <mgorny@g.o>