-----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-----
