forked from FabioLolix/LinuxTimeline
-
Notifications
You must be signed in to change notification settings - Fork 0
/
CONTRIBUTING
115 lines (90 loc) · 4.33 KB
/
CONTRIBUTING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
Linux Distribution Timeline | CONTRIBUTING
------------------------------------------
Because I want to keep it simple and coherent with previous versions by
the original maintainers, I decided to make this very simple guide of
how to contribute to this project. You are not obliged to follow this,
but you'll ease my job if you do. :)
Open an issue on github
=======================
Just open an Issue in GitHub and fill in the template.
If you don't want to open a GitHub account leave a comment on blogspot
https://fabiololix.blogspot.it/2016/08/linux-distribution-timeline.html
or contact me on Twitter or Manjaro forum
https://twitter.com/Fabio_Lolix
https://forum.manjaro.org/users/Lolix/
or by mail at [email protected]
Pull Request on github, proceed below
==========
Formatting
Since we're working with CSV format, you can fill the right column
rather easily, since it is self-explanatory.
If you edit the CSV using LibreOffice Calc, make sure to load the file
with "Quoted field as text" enabled to prevent autoformatting.
Remember to keep the CSV coherent, newest distro will always go to the
lowest place. And also, please group it accordingly, a Debian-based
distro should never be grouped with a distro based on Red Hat.
I'll just give an example of how we can get it done.
"Debian"
"Ubuntu" based on Debian
"Kubuntu" based on Ubuntu
"Linux Mint" based on Ubuntu
"Crunchbang" based on Debian
"Red Hat"
"Fedora Core" based on Red Hat
"CentOS" based on Red Hat
Keep the original timeline
==========================
Don't understand what I meant? For example, S.u.S.E, before rebasing
their code to Red Hat, they originally used Slack as their upstream. If
you ever see this happening in the future, add it to the connectors,
again, coherent with the distros. You may see "Thickness" in the CSV in
the "Connectors" part. The thickness may vary from 1, 2 or 4. It has
already been explained in the build generated by gldt, but I'll just
explain it again.
1: Influence, developer switch
(e.g.: CRUX to Arch)
2: Rebasing, substantial code flow, project overtaking
(e.g. Red Hat to SuSE)
4: Developer & code sharing, project merging
(e.g. Maemo to MeeGo)
Announcement date OR first stable release?
==========================================
For start dates, it is preferred to use an announcement date. However,
if you have no information of announcement date (or you are too lazy to
find information about it) then you can use first stable release just
fine.
Dead Distros
============
People get bored with maintaining a dead distro with no interest from
the Linux community. Some of them have announcements on whether they
will discontinue it, or just killing it silently, or even better,
killing the whole website. What to do in these kinds of situation?
1. If the distro has an announcement or statement on discontinuing the
distro, use the announcement date as stop date
2. If the distro has no news since last release but still have a pretty
much active forums/community (even small), consider it active.
3. If it has no information of forums, but the website is active, and
if it has no release since 3 years after its latest stable release,
put the stop date on latest stable release + 3 years
4. If the website is dead and there's no other information, put the
stop date on last stable release + 1 year
EXCEPTIONS:
If a distro announced its discontinuation (which effectively making a
date being it's stop date) and a fork of the discontinued distro is
announced after a distro is discontinued, push the stop date of the
upstream distro (which is the discontinued one) to the first
announcement (or first stable release) of the fork distro. Case in
point: MeeGo (to Mer and Tizen).
Another interesting case is CrunchBang, it was discontinued, but it has
two forks, one declared as its successor (BunsenLabs), if this case were
to happen again:
1. If the discontinued distro's maintainers declared a distro as their
successor (even if it is originally a fork), do NOT discontinue the
main distro, instead, put a new name on that distro (I guess if you
regularly worked on the csv, you'll know what I mean).
2. If the discontinued distro's maintainers doesn't decide on successors,
then use the usual forking.
P.S.
====
Please avoid fuss about GNU/Linux vs Linux and GNU/Linux vs Android
This will **maybe** be sorted out in the future