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