2.6.24 - time to switch

Werner Almesberger werner at openmoko.org
Fri Feb 1 20:35:39 CET 2008

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.

> and although we don't seem to worry much
> about it right now, Signed-off-by.

Yes, these are very inconsistent :-(

They're in fact also the point where the "patch file" and "commit
sequence" view don't intersect gracefully, for signing off a patch
that gets added to, say, smedia-glamo.patch neither means that one
is signing off smedia-glamo.patch as a whole, nor does it mean that
anyone's "signature" that isn't on that new patch should also be
removed from smedia-glamo.patch.

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

Whether and where we record authorship then becomes an independent

> Vast and mighty is the suckage and pain level in that system.

Indeed. What's worse is that it's basically impossible to automate
and it's open loop. So all the mistakes made during manual 
rearranging propagate right through to the repository and needs to
be fixed later.

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

That's why I'm afraid of straying from the past course. Doing a bit of
editing ten times a day still sounds less painful than having to go
through a thousand patches after a few months.

Be assured that I'm very awars of the appeal of just tossing in the
patches quickly, and putting off all worries about how to move them
upstream for some vague "later" ;-)

Of course, the current situation is worse that it ever was, because
we don't only have the growing anomalous (i.e., unmerged) patch
collection, but also development work happens in two differently
structured trees, while in the past, besides a small trickle of
patches from the developers in Taiwan, who generally didn't commit
directly, everybody was working on the SVN+quilt tree, and thus
almost automatically followed the existing structure. Thus, the
burden for the "gateway" person was much lower.

> Clearly when we compose a nontrivial patchset as the author, we have
> choices about how to cut them into layers of patches.  But the layers
> don't really conform to "seams" that work along file lines.
> And a unitary patch we send upstream will not conform to discrete file
> borders either -- it might do one function but touch five files and that
> is the smallest footprint that is possible, and upstream will be happy
> to see that as a single patch.  I don't think per-file patches gets you
> anywhere good at all.

Yes, life would be so much easier without the overlaps :-) What often
works well is to separate such patches into a "private files" and a
"shared files" part, with the understanding that they only work if
applied together.

Of course, all this gets messy if many such overlapping patches get
layered on top of each other. That's why I call the current situation
anomalous: we have the structure that would allow us to push patches
upstream rapidly, but we currently don't have the resources to
actually start and maintain that process.

> Going to do some more thinking about it, clearly it is a big question.

Oh yes, it is :)

- Werner

More information about the openmoko-kernel mailing list