Linux development process - Revision history

Lilith2 at 14:55, 11 August 2015

2015-08-11T14:55:09Z

Lilith2 at 14:30, 11 August 2015

2015-08-11T14:30:44Z

Lilith2 at 14:26, 11 August 2015

2015-08-11T14:26:49Z

Lilith2: /* Kernel */

2015-08-02T10:57:53Z

‎Kernel

Lilith2: /* Related */

2015-07-22T21:15:55Z

‎Related

Lilith2: /* Threading carefully: init scripts */

2015-07-21T19:18:18Z

‎Threading carefully: init scripts

Lilith2: /* Threading carefully: init scripts */

2015-07-21T19:05:22Z

‎Threading carefully: init scripts

Lilith2: /* Upstream and downstream */

2015-07-21T19:00:03Z

‎Upstream and downstream

Lilith2 at 18:41, 21 July 2015

2015-07-21T18:41:09Z

Lilith2 at 00:11, 19 July 2015

2015-07-19T00:11:22Z

← Older revision		Revision as of 14:55, 11 August 2015
Line 1:		Line 1:
−
−	~~== Upstream and downstream ==~~
−
	From the perspective of a linux distro, ''upstream'' usually refers to the original author(s) of the source code for a particular package. Downstream may refer to a distribution that has forked/branched from the perspective of the distro you are looking at.		From the perspective of a linux distro, ''upstream'' usually refers to the original author(s) of the source code for a particular package. Downstream may refer to a distribution that has forked/branched from the perspective of the distro you are looking at.

@@ Line 1: / Line 1: @@
 == Upstream and downstream ==
@@ Line 28: / Line 27: @@
 == Related ==
 * [[Captivating capital and copyfighting]]
 * [[Linux virtualisation]]
 * [[Making our own linux images]]

@@ Line 1: / Line 1: @@
 [[File:Dontpanic.jpg|640px|thumb|right]]
 == Upstream and downstream ==
@@ Line 52: / Line 16: @@
 Merging source code upstream takes effort, dedication and time. The threshold for getting source code accepted into the Linux kernel is relatively high. If bad quality code got accepted, maintaining the linux kernel would become much more difficult.
 == Package development ==
@@ Line 132: / Line 25: @@
 * The kernel guide http://www.linux.org/threads/linux-kernel-reading-guide.5384/
 * LinuxChanges http://kernelnewbies.org/LinuxChanges
 == Related ==

@@ Line 130: / Line 130: @@
 * A Guide to the Kernel Development Process http://www.linuxfoundation.org/content/1-guide-kernel-development-process
 * The Linux Kernel Archives https://www.kernel.org/
 * The kernel guide http://www.linux.org/threads/linux-kernel-reading-guide.5384/
 === Init systems ===

@@ Line 144: / Line 144: @@
 == Related ==
 * [[Captivating capital and copyfighting]]
 * [[Installing linux]]
 * [[Linux applications]]
 == References ==

@@ Line 55: / Line 55: @@
 == Threading carefully: init scripts ==
-Jessie now installs systemd by default http://ewontfix.com/14/:
+In Unix-based computer operating systems, init (short for initialization) is the first process started during booting of the computer system. Init is a daemon process that continues running until the system is shut down. It is the direct or indirect ancestor of all other processes and automatically adopts all orphaned processes. Init is started by the kernel using a hard-coded filename; a kernel panic will occur if the kernel is unable to start it. Init is typically assigned process identifier 1 (PID 1).
 ''So how should init be done right?''
@@ Line 61: / Line 63: @@
 * ''The Unix way: with simple self-contained programs that do one thing and do it well. Get everything out of PID 1.''
 * ''The systemd way https://people.debian.org/~stapelberg/docs/systemd-dependencies.html: Take advantage of special properties of pid 1 to the maximum extent possible. This leads to ever-expanding scope creep and exacerbates all of the problems described in http://ewontfix.com/14/ (and probably many more yet to be discovered).''
-''The right way: Do away with everything special about pid 1 by making pid 1 do nothing but start the real init script and then just reap zombies (see script by Rich Felker below)''
+=== PID 1 ===
-−
-=== Init ===
 ''There has been some interest in having a proper free software license on the trivial init code included below. I originally considered it too trivial to even care about copyright or need a license on it, but I don't want this to keep anyone from using or reusing it, so I'm explicitly licensing it under the standard MIT license'' ~ Rich Felker

@@ Line 43: / Line 43: @@
 So if Debian receives a bug relating to Apache, then a package maintainer or anyone reading the bugs may do some investigation. If they determine the bug to be in the original source code, and not caused by something unique to the distro they will work with the upstream authors to work on fixing the bug in program.
-If the upstream developer of the troublesome package is uncooperative or went awol, then the investigating developer may add a patch that applies to the package. This can be seen as a (hopefully temporary) fork of upstream development.
+If the upstream developer of the troublesome package is uncooperative or went awol, then the investigating developer may add a patch to the package. This can be seen as a (hopefully temporary) fork of upstream development. Once bug and maintainer are found and bug is solved, Debian may work with ''downstream'' distros like Ubuntu to make sure the bug is fixed everywhere. Downstream maintainers can also submit issues related to things having to do with a packaging or any patches added.
-Once the bug is found and solved one way or another, Debian may work with ''downstream'' distros like Ubuntu to make sure the bug is fixed everywhere. Downstream maintainers can also submit issues related to things having to do with a packaging or any patches added.
+If we are working on something like mint, which is based on ubuntu, which in turn is based on debian, the term upstream could mean any one of the maintainers of mint, ubuntu and debian, or it could refer to the original author(s) of a package. When maintainers and author(s) of packages are working well together usually all of them will be subscribed to similar lists, and bugtrackers and anyone with some responsibility for a given package will be notified in some form about bugs and new patches made at any level.
-−
-If we are working on something like mint, which is based on ubuntu, which in turn is based on debian, the term upstream could mean any one of the maintainers between mint up until debian, or it could refer to the original author(s) of a package. When maintainers and author(s) of packages are working well together usually all of them will be subscribed to similar lists, and bugtrackers and anyone with some responsibility for a given package will be notified in some form about bugs and new patches made at any level.
 == Kernel development ==

@@ Line 36: / Line 36: @@
 Not every desktop program is a part of a particular desktop environment. For example, Firefox and Icedove are not tied to a particular desktop environment. You can run any Linux desktop program in any desktop environment, but it can (and most likely will drag in other processes). For example, if you tried to install the Nautilus file manager on KDE, it will attempt to install a variety of GNOME libraries and probably start GNOME desktop processes in the background when you open it. It would work, you can use it, at a performance price. For a list of growing wishes see [[Linux applications]].
 == Kernel development ==
-== Threading carefully ==
+On occasion code is merged into the upstream kernel, the kernel tree managed by Linus Torvalds and available from kernel.org.
-Jessie installs systemd by default. This lack of choice is against point 4 of the Debian Social Contract https://www.debian.org/social_contract.en.html. And not only that: http://ewontfix.com/14/:
+Jessie now installs systemd by default http://ewontfix.com/14/:
 ''So how should init be done right?''