stable-tracking test image

Andy Green andy at
Tue Nov 18 11:02:35 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> We'll see how it goes, but I think we can find that the branches based
|> on other branches are cheap to maintain and can generally be treated as
|> standins for the branch they're based on.  Ie treat a maintained
|> andy-tracking or balaji-tracking as
| Let's say we hit a PMU problem while the upstream submission is in
| transit. In which branch would we fix it ? Seems a bit wasteful to do
| it in code that's already known to be obsolete. Also, we might end up
| with people using either branch (perhaps by proxy), which ought to be
| confusing.
|> Since we will hopefully eventually have several pending upstream patches
|> we need a way to deal with it generally, leaving stable-tracking clean
|> and ready for them coming back upstream is the first plan anyway.
| Hmm, but there will be conflicting code anyway, won't there ?
| I can see that you may want to keep a branch with the upstream changes
| that gets frozen at the time of submission, so that one can later diff
| against it to see if the changes have mutated on their round-trip or if
| we've made significant changes since then.

Each time we had these "nothing is possible" threads we managed to move
forward fine.  We'll see how we go with this method and adapt if it
starts causing pain... since the pain will be delivered to my ass mainly
I will be quite open to adapting to minimize it :-)

The upgraded stable and andy-tracking will be coherent for our upstream
stuff, it should be enough to share patches between them pretty easily
so even the pending stuff can be grown on top of and then there is a
path to bulk-update stable-tracking when the pending stuff arrives.  So
I think we cover enough bases that we stand a good chance with the first
method and track enough that we can change method if it turns out we
have to.  FWIW the 6410 integration to a single tree that sounded scary
also "just worked" in the end.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list