2.6.24 - time to switch

Andy Green andy at openmoko.com
Sat Feb 2 11:57:08 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
> Andy Green wrote:
>> Well it sucks because we lost the other attributes of the patch, the
>> commit log entry, attribution
> They're not in the patch file per se, but they're in the commit log.
> That's the two-layered architecture we have with SVN+quilt. If you
> want to function for upstream, you just pick the patch file. If you
> need to actually maintain the beast, you go by the commits.

This structure makes another problem, the various incarnations of these
mokopatch blobs do not contain information about the full tree they
patched against.  All that's in there is a history of patch accretion.

It means if we peel off the onion skins that make the mokopatches in
order to reapply them in git for history, the inner, earliest patches
probably won't apply to a modern 2.6.24 tree (they originally worked
with 2.6.0 or whatever), even though the whole onion would.

Well it's not death but another sign we need to get off Mokopatches.

> anyone's "signature" that isn't on that new patch should also be
> removed from smedia-glamo.patch.

Yeah... well there are two things with Signed-off-by, attribution and
ass-covering.  Avoiding quoting bits of the GPL manfully -- I think it
is an issue to note somehow that we took in a particular person's
contribution in a clear way naming names and contact details.  The
mailing list takes care of it in a timestamped way.  And the ass-covering:

> All this means that we're probably just going through the motions
> with that signing off, and what really needs to be done is that,
> before a patch is submitted upstream, it gets a final review and
> that/those final reviewer(s) adds the only "Signed-off-by".

I think whoever signs off on it upstream needs to have a reachable
directory of who signed off on what *to him*.  Otherwise his ass in on
the line not the guy who copied SCO's "valuable intellectual property"
or whatever and gave it to him for composition into a mokopatch, etc.
His ass definitely doesn't need to be on the line if we just do what
upstream does and require a Signed-off-by on everything.

>> A question is if the work you do at the front end of accreting patches
>> into mokopatch worlds is better done at the moment before we issue a
>> patch upstream, considering we can use techniques like virtual patch
>> merging filtered by filesets affected or some other patch-granular
>> transformation.
> That's a good question. Unfortunately, the only way to find out would
> be to try, and if it doesn't work, we'd see this by everybody running
> away from the task, leaving a huge unmaintainable pile of patches and
> no maintainers.

You don't have to worry about that: you won't have to change until we
have a chance to evaluate a new system running in parallel with the old
one and you can satisfy yourself that overall it sucks less.  During
that we go on continuously with the ago--- er, Mokopatches.

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


More information about the openmoko-kernel mailing list