Kernel Plans

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Patchwork)
(Upstream Linux kernel)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.
+
This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions.
  
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.
+
== Current priority ==
 +
 
 +
The current priority is to make the andy-tracking branch stable.
 +
 
 +
See: https://docs.openmoko.org/trac/milestone/stable-kernel-2009.1
  
 
== Patch review process ==
 
== Patch review process ==
Line 8: Line 12:
  
 
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like "i like this patch") but we don't know if we can count on this.
 
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like "i like this patch") but we don't know if we can count on this.
 
  
  
 
== Use tags and not forks for stable kernels ==
 
== Use tags and not forks for stable kernels ==
 +
 +
The next stable kernel will be stable-kernel-2009.1. This is [http://docs.openmoko.org/trac/query?status=in_testing&status=reopened&status=assigned&status=new&status=accepted&group=status&milestone=stable-kernel-2009.1 the list of the bugs that need to be fixed] for it to happen.
  
 
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.
 
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.
Line 19: Line 24:
 
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).
 
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).
  
We could fork the current Andy-tracking into a stable kernel. But, should we really do it? People could fork a stable tree and cherry-pick changes.
+
If the tagging approach fails for us we'll create a stable branch but let's delay this action until we actually need it.
  
 
== Upstream Linux kernel ==
 
== Upstream Linux kernel ==
  
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.
+
For the next merge window we wish to send:
 +
 
 +
* Basic GTA02 support (Update: sent and [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-November/010695.html included])
 +
* Touchscreen Driver and filters
 +
 
 +
See:
 +
 
 +
* http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009740.html
 +
* http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009450.html + http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ts-with-s3c-adc/
  
 
== Issues to solve ==
 
== Issues to solve ==
Line 29: Line 42:
 
=== Define how to keep track of the upstream kernel ===
 
=== Define how to keep track of the upstream kernel ===
  
How to up-level the kernel to latest upstream version? (We can delay this decision for a few days).
+
How to up-level the kernel to latest upstream version? (We can delay this decision).
 +
 
 +
=== Make a better use of trac ===
 +
 
 +
There are many bugs that might be invalid. If you reported a bug and/or you know it is no longer valid please ask us to close it (this can be done in the same bug report).
 +
 
 +
We'll use milestones to filter the noise and to be able to focus on the important bugs.
 +
 
 +
=== Patchwork ===
 +
 
 +
We have a patchwork installation ( http://patchwork.openmoko.org ) requested by Angus but it still have some issues. It would be nice to use it in the future.
 +
 
 +
See:
 +
 
 +
* http://ozlabs.org/~jk/projects/patchwork/ (Patchwork)
 +
* http://patchwork.ozlabs.org (Patchwork in use)
 +
 
 +
[[Category:Kernel]]

Latest revision as of 23:27, 15 November 2009

This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions.

Contents

[edit] Current priority

The current priority is to make the andy-tracking branch stable.

See: https://docs.openmoko.org/trac/milestone/stable-kernel-2009.1

[edit] Patch review process

If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.

Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like "i like this patch") but we don't know if we can count on this.


[edit] Use tags and not forks for stable kernels

The next stable kernel will be stable-kernel-2009.1. This is the list of the bugs that need to be fixed for it to happen.

We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.

We will tag stable kernels in the repository.

We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).

If the tagging approach fails for us we'll create a stable branch but let's delay this action until we actually need it.

[edit] Upstream Linux kernel

For the next merge window we wish to send:

  • Basic GTA02 support (Update: sent and included)
  • Touchscreen Driver and filters

See:

[edit] Issues to solve

[edit] Define how to keep track of the upstream kernel

How to up-level the kernel to latest upstream version? (We can delay this decision).

[edit] Make a better use of trac

There are many bugs that might be invalid. If you reported a bug and/or you know it is no longer valid please ask us to close it (this can be done in the same bug report).

We'll use milestones to filter the noise and to be able to focus on the important bugs.

[edit] Patchwork

We have a patchwork installation ( http://patchwork.openmoko.org ) requested by Angus but it still have some issues. It would be nice to use it in the future.

See:

Personal tools

This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.

We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.

Patch review process

If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.

Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like "i like this patch") but we don't know if we can count on this.


Use tags and not forks for stable kernels

We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.

We will tag stable kernels in the repository.

We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).

We could fork the current Andy-tracking into a stable kernel. But, should we really do it? People could fork a stable tree and cherry-pick changes.

Upstream Linux kernel

We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.

Issues to solve

Define how to keep track of the upstream kernel

How to up-level the kernel to latest upstream version? (We can delay this decision for a few days).