On 12/3/2010 10:00 AM, Olsen, Alan R wrote:
[Sorry about the top posting. Outlook is evil.]
The problem is there are a number of patches in the Meego kernel that do not apply
cleanly to a git tree. Either they are raw diffs, git patches that were generated with
"git show" or gitweb, or patches that had the headers stripped off.
If you try to reconstruct a real git tree with history you encounter a number
of problems. The above patches that do not apply cleanly is just one. The Alan
Cox patchset from 08-24-10 is no longer representative of the patches in the
Alan Cox tree because of continual modifications to that patch since that date.
The biggest conflict is the eMMC patch pulled from 2.6.37-rc1 that is inserted
before the AC patch. The AC patch was modified in a way that does not fit the
history cleanly. (That patch should have been added after the AC patchset.)
There is also the issue of the cherrypick patch, which is just a big raw diff
with no signoffs. History for this cannot be reconstructed because there is no
clue as to what patches this blob represents.
There is also the issue of the compat-wireless that was hacked into the
kernel.spec.in file. For my builds I just create a patch instead. (It was an
interesting surprise, to say the least...)
I can provide a list of all the patches that do not apply correctly. The reason
that we need history is that I have customers requesting a real git tree with
actual history. Quilt just does not cut it for that customer and for internal
development.
since MeeGo is not a development target, the last is not a MeeGo
problem. MeeGo is for INTEGRATION of mature code.
MeeGo does keep history, but it keeps the history of the *patches*, not
if the code. This is the very fundamental difference of INTEGRATION
versus DEVELOPMENT.
Lets take the eMMC change. That is an upstream backport, and thus has to
be done first in the series (so that when we rebase to a new kernel, we
can just drop the top X patches).... and to be closer to upstream code level
at the time of doing the backport. You can't really do it later in the
series.
All the non-upstream patches have to come after that... simple as that. ..
Patch ordering in the MeeGo *integration* kernel is not "tack at the
end" chronological, but put in a logical place to reduce interactions
and make maintenance easier/possible.
Git *development* uses a different, strictly chronological model.....
which is very well suited for development.
_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel
