Kernel branches

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Welcome to the jungle inoccent wiki page.)
(-cats)
 
(14 intermediate revisions by one user not shown)
Line 1: Line 1:
This page started with a copy of [[http://lists.openmoko.org/pipermail/openmoko-kernel/2008-November/006945.html this email]] sent by Andy Green to the kernel list.
+
== Introduction ==
  
 +
This page explains how we take advantage of GIT branches for kernel development at Openmoko. The [[Kernel]] page is the sister of this page.
  
A fair amount of "administrivia" has built up, here's the executive summary:
+
'''Note''': At the moment we are only using the andy-tracking branch. This will change soon.
  
~ 1) *-tracking branches in git have a history now
+
=== How we use GIT History ===
~ 2) pending-tracking created
+
~ 3) how it is decided what goes on which branch
+
~ 4) all patches end up in stable-tracking
+
~ 5) we will fork the new stable from andy-tracking
+
~ 6) target andy-tracking for patches
+
  
Rest of the email is explaining how or why.
+
The branches whose names end in -tracking have a history in GIT. This history allows us to go back and to check who did what and when it happened.
  
 
+
Committed patches appear directly on the branch they were
1) *-tracking branches in git have a history now
+
committed on.  If a patch goes into stable-tracking it will appear
 
+
The last few days I have been using a new system in git where I hide the
+
hard rebases that are happening on my local tree for the -tracking
+
branches and instead make "MERGE" commits on the upstream branches.  It
+
seems to be working out so far so I explain what's going on.
+
 
+
Committed patches now only appear directly on the branch they were
+
committed on.  So if a patch goes into stable-tracking it will appear
+
 
there as normal, but what appears in the downstream branches rebasing
 
there as normal, but what appears in the downstream branches rebasing
 
off that is a single MERGE commit that contains whatever the diff is
 
off that is a single MERGE commit that contains whatever the diff is
between the unrebased and rebased version of that branch. Since I
+
between the unrebased and rebased version of that branch. Since Andy
rebase very often, it won't be unusual that the MERGE version used
+
rebases very often, it will not be unusual that the MERGE version used
 
downstream is just the one added upstream patch content, but it can also
 
downstream is just the one added upstream patch content, but it can also
 
be typical that the MERGE commit will contain the changes from dozens or
 
be typical that the MERGE commit will contain the changes from dozens or
Line 35: Line 23:
 
being hard rebased constantly.
 
being hard rebased constantly.
  
 +
== andy-tracking ==
  
2) pending-tracking created
+
We will fork stable kernels from this branch.
  
It's become clear we can end up with a bunch of patches from several
+
Think of this as the branch where most of the action takes place (at least for most of us).
directions heading into various upstreams if we're lucky. So I have
+
If you simply target andy-tracking for patches, the resulting patch will
introduced a "pending-tracking" that fits inbetween stable-tracking and
+
automatically be ready for either andy-tracking, pending-tracking
 +
(usually) or stable-tracking depending on what it touched.
 +
 
 +
If in doubt ask in the [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel mailing list].
 +
 
 +
== pending-tracking ==
 +
 
 +
We can end up with a bunch of patches from several
 +
directions heading into various upstreams if we're lucky.
 +
 
 +
We have a "pending-tracking" that fits in between stable-tracking and
 
andy-tracking, to temporarily hold all the patches that are expected to
 
andy-tracking, to temporarily hold all the patches that are expected to
 
come from upstream eventually.  Balaji-tracking feeds into this now, but
 
come from upstream eventually.  Balaji-tracking feeds into this now, but
 
there's other stuff like Matt's patches headed for s3c64xx upstream too.
 
there's other stuff like Matt's patches headed for s3c64xx upstream too.
~ This also allows me to publicly rebase Balaji's patches without writing
+
 
in balaji-tracking, and it also allows me to track changes from
+
This allows for Balaji's patches being rebased without writing
 +
in balaji-tracking, and it also allows Andy to track changes from
 
balaji-tracking and elsewhere in one place too.
 
balaji-tracking and elsewhere in one place too.
  
 +
== Some patch work-flow before introducing stable-trackig ==
  
3) How is it decided what goes on which branch
+
Patch belongs in upstream, eg, Linus or Ben Dooks tree -->
 
+
~ - Patch belongs in upstream, eg, Linus or Ben Dooks tree -->
+
 
pending-tracking.  It's kept segregated because we expect it to turn up
 
pending-tracking.  It's kept segregated because we expect it to turn up
 
by upstream rebase path; if it changes on the way we can adapt it in
 
by upstream rebase path; if it changes on the way we can adapt it in
 
pending-tracking and rebase
 
pending-tracking and rebase
  
~ - Patch bases on stuff in pending-tracking, eg uses Balaji regulator
+
Patch bases on stuff in pending-tracking, eg uses Balaji regulator
 
things  --->  andy-tracking.  It's kept segregated because "it lives in
 
things  --->  andy-tracking.  It's kept segregated because "it lives in
 
the future" where the pending upstream patches arrived upstream.
 
the future" where the pending upstream patches arrived upstream.
  
~ - Neither of the above ---> stable-tracking
+
Neither of the above ---> stable-tracking
  
 +
== stable-tracking ==
  
4) All patches end up in stable-tracking.
+
All patches end up in this branch, that's what it expects.
  
 
Stuff temporarily in pending-tracking will eventually turn up from
 
Stuff temporarily in pending-tracking will eventually turn up from
Line 75: Line 75:
 
in andy-tracking gravitate to stable-tracking as soon as possible too.
 
in andy-tracking gravitate to stable-tracking as soon as possible too.
  
 
+
== More patch work-flow ==
5) We will fork the new stable from andy-tracking
+
  
 
Because andy-tracking is "living in the future" with latest pending
 
Because andy-tracking is "living in the future" with latest pending
Line 82: Line 81:
 
these even at the risk the patches will be rejected upstream.
 
these even at the risk the patches will be rejected upstream.
  
 +
== proposed ==
  
6) Target andy-tracking for patches
+
This is a temporal branch with no history. We use it as a temporal playground so that we can get patches ready for upstream.
  
If you simply target andy-tracking for patches, the resulting patch will
+
== Credits ==
automatically be ready for either andy-tracking, pending-tracking
+
 
(usually) or stable-tracking depending on what it touched.
+
This page started as an improvement of [http://lists.openmoko.org/pipermail/openmoko-kernel/2008-November/006945.html this email] sent by Andy Green to the [[Openmoko]] kernel list.
 +
 
 +
{{Languages|Kernel_branches}}
 +
 
 +
 
 +
[[Category:Kernel]]

Latest revision as of 08:21, 19 July 2009

Contents

[edit] Introduction

This page explains how we take advantage of GIT branches for kernel development at Openmoko. The Kernel page is the sister of this page.

Note: At the moment we are only using the andy-tracking branch. This will change soon.

[edit] How we use GIT History

The branches whose names end in -tracking have a history in GIT. This history allows us to go back and to check who did what and when it happened.

Committed patches appear directly on the branch they were committed on. If a patch goes into stable-tracking it will appear there as normal, but what appears in the downstream branches rebasing off that is a single MERGE commit that contains whatever the diff is between the unrebased and rebased version of that branch. Since Andy rebases very often, it will not be unusual that the MERGE version used downstream is just the one added upstream patch content, but it can also be typical that the MERGE commit will contain the changes from dozens or hundreds of patches when the Linus tree updates or example.

The reason for this new way is that it gives the public -tracking branches a linear history that you can rewind, despite that they are being hard rebased constantly.

[edit] andy-tracking

We will fork stable kernels from this branch.

Think of this as the branch where most of the action takes place (at least for most of us). If you simply target andy-tracking for patches, the resulting patch will automatically be ready for either andy-tracking, pending-tracking (usually) or stable-tracking depending on what it touched.

If in doubt ask in the mailing list.

[edit] pending-tracking

We can end up with a bunch of patches from several directions heading into various upstreams if we're lucky.

We have a "pending-tracking" that fits in between stable-tracking and andy-tracking, to temporarily hold all the patches that are expected to come from upstream eventually. Balaji-tracking feeds into this now, but there's other stuff like Matt's patches headed for s3c64xx upstream too.

This allows for Balaji's patches being rebased without writing in balaji-tracking, and it also allows Andy to track changes from balaji-tracking and elsewhere in one place too.

[edit] Some patch work-flow before introducing stable-trackig

Patch belongs in upstream, eg, Linus or Ben Dooks tree --> pending-tracking. It's kept segregated because we expect it to turn up by upstream rebase path; if it changes on the way we can adapt it in pending-tracking and rebase

Patch bases on stuff in pending-tracking, eg uses Balaji regulator things ---> andy-tracking. It's kept segregated because "it lives in the future" where the pending upstream patches arrived upstream.

Neither of the above ---> stable-tracking

[edit] stable-tracking

All patches end up in this branch, that's what it expects.

Stuff temporarily in pending-tracking will eventually turn up from upstream pulls, at that time it's no longer pending and is part of what stable-tracking rebased against. The now duplicate patch in pending-tracking is then removed. The patch ended up in stable-tracking.

Once the pending-tracking patch became part of stable-tracking, there is no reason for the patches modifying or depending on it held until now in andy-tracking not to merge back into stable-tracking either. So patches in andy-tracking gravitate to stable-tracking as soon as possible too.

[edit] More patch work-flow

Because andy-tracking is "living in the future" with latest pending upstream patches included, it makes sense to take the advantage from these even at the risk the patches will be rejected upstream.

[edit] proposed

This is a temporal branch with no history. We use it as a temporal playground so that we can get patches ready for upstream.

[edit] Credits

This page started as an improvement of this email sent by Andy Green to the Openmoko kernel list.

Personal tools

This page started with a copy of [this email] sent by Andy Green to the kernel list.


A fair amount of "administrivia" has built up, here's the executive summary:

~ 1) *-tracking branches in git have a history now ~ 2) pending-tracking created ~ 3) how it is decided what goes on which branch ~ 4) all patches end up in stable-tracking ~ 5) we will fork the new stable from andy-tracking ~ 6) target andy-tracking for patches

Rest of the email is explaining how or why.


1) *-tracking branches in git have a history now

The last few days I have been using a new system in git where I hide the hard rebases that are happening on my local tree for the -tracking branches and instead make "MERGE" commits on the upstream branches. It seems to be working out so far so I explain what's going on.

Committed patches now only appear directly on the branch they were committed on. So if a patch goes into stable-tracking it will appear there as normal, but what appears in the downstream branches rebasing off that is a single MERGE commit that contains whatever the diff is between the unrebased and rebased version of that branch. Since I rebase very often, it won't be unusual that the MERGE version used downstream is just the one added upstream patch content, but it can also be typical that the MERGE commit will contain the changes from dozens or hundreds of patches when the Linus tree updates or example.

The reason for this new way is that it gives the public -tracking branches a linear history that you can rewind, despite that they are being hard rebased constantly.


2) pending-tracking created

It's become clear we can end up with a bunch of patches from several directions heading into various upstreams if we're lucky. So I have introduced a "pending-tracking" that fits inbetween stable-tracking and andy-tracking, to temporarily hold all the patches that are expected to come from upstream eventually. Balaji-tracking feeds into this now, but there's other stuff like Matt's patches headed for s3c64xx upstream too. ~ This also allows me to publicly rebase Balaji's patches without writing in balaji-tracking, and it also allows me to track changes from balaji-tracking and elsewhere in one place too.


3) How is it decided what goes on which branch

~ - Patch belongs in upstream, eg, Linus or Ben Dooks tree --> pending-tracking. It's kept segregated because we expect it to turn up by upstream rebase path; if it changes on the way we can adapt it in pending-tracking and rebase

~ - Patch bases on stuff in pending-tracking, eg uses Balaji regulator things ---> andy-tracking. It's kept segregated because "it lives in the future" where the pending upstream patches arrived upstream.

~ - Neither of the above ---> stable-tracking


4) All patches end up in stable-tracking.

Stuff temporarily in pending-tracking will eventually turn up from upstream pulls, at that time it's no longer pending and is part of what stable-tracking rebased against. The now duplicate patch in pending-tracking is then removed. The patch ended up in stable-tracking.

Once the pending-tracking patch became part of stable-tracking, there is no reason for the patches modifying or depending on it held until now in andy-tracking not to merge back into stable-tracking either. So patches in andy-tracking gravitate to stable-tracking as soon as possible too.


5) We will fork the new stable from andy-tracking

Because andy-tracking is "living in the future" with latest pending upstream patches included, it makes sense to take the advantage from these even at the risk the patches will be rejected upstream.


6) Target andy-tracking for patches

If you simply target andy-tracking for patches, the resulting patch will automatically be ready for either andy-tracking, pending-tracking (usually) or stable-tracking depending on what it touched.