new kernel ... / meaning of stable-tracking

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

|> We still have to cover some history for Balaji, for example the
|> mokopatches layer and GTA01 in fact, pcf50633 relationship to pcf50606
|> used on GTA01 -- GTA01 aspect at all -- and shared includes that exist.
|> ~ If we're going to do it better to do it on the list.
|>
| Hi Andy,
|
| Yes, I was wondering what the mokopatches thing actually is.

(I stuck the list back on)

Before we started using git, we tried a different technique based around
svn.  If a patch was submitted, it was broken apart and its pieces
distributed between various topic patches that were all that was
maintained.  So individual patches got disappeared and all that was left
was growing topic patches.  (The submitter of the patches then had a fun
time rebasing on the topic patches and destroying his own patch each
time on his local tree).

The mokopatches branches in git are what's left of these huge topic
blobs at the point in time we switched to git on top of them.  So the
stable for example is

master (at 2.6.24 tag) -> mokopatches -> stable

You can treat mokopatch branches as just another patchset on upstream to
be applied before the other branches.  mokopatches-tracking is just an
upleveled, rebased version of mokopatches then that applies to upstream
HEAD.

|> There's no doubt this scheme will work in itself.
|>
|> The rebasing action is not an easy job for Balaji but he sounds like it
|> doesn't faze him.  Otherwise the troubles are going to come from
|> upstream response to stuff like no regulator API in pcf50633, need to
|> bitbang in lis302dl, etc
|
| Yes, I only had a vague estimate of how difficult could it be. But your
| comment makes me feel that I'm wrong :) But it's ok. If it takes more
hard
| work, I'm ready and I'll have to learn and grow anyway. So, I still
| believe I can do it.

If you can handle this you will certainly come out of it with some
strong arms.  We'll help you, the main thing is get one step straight at
a time and don't get in the position you try to do everything before
there is any contact to upstream to complete the circle.  The moment you
get one patch in upstream you'll get fire in your belly for sure about
the rest of it, since it will be proven possible :-)

| Oh, the latter part of the comment seems a bit scary. Oh, what do we do
| about the regulator API ? Isn't it simple to provide one ? I was reading
| through the 'Linear Regulator' part of the user manual.

pcf50633 is not the least delicate part of our stuff.  Retrofitting new
APIs like regulator in there and other places that touch it without
breaking something is quite a little job all by itself.

What I think I would suggest is to go through the steps we talked about
already to form a clean add-pcf50633-support-to-mainline.patch, and then
approach upstream with it explaining the situation as an RFC about what
absolutely has to be changed.  Maybe they have mercy about regulator API
because we are nice guys, we dunno.  Then discuss the results of it on
this list and we figure out what to do.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjXmf0ACgkQOjLpvpq7dMrn1wCePPGbRoT0XGnMpLi0DahQNn4A
558Ani5QCSqv/YT/JMYgsThZYlnnhaml
=A5oJ
-----END PGP SIGNATURE-----