KS2008: Development tools

Posted Sep 16, 2008 11:45 UTC (Tue) by johill (subscriber, #25196)
Parent article: KS2008: Development tools

One thing about patchwork that confuses me is it's independence of git entirely, couldn't it go create git branches for each patch and then track a git tree on whether a patch made it in or not? Or have it work with topgit.

That way, much of the work done in patchwork (tracking the status of a patch) could be automatic, if a patch gets merged then it knows automatically. Hey, it could even warn that you've merged v2 of a patch but v3 was available...

KS2008: Development tools

Posted Sep 16, 2008 22:42 UTC (Tue) by jk (subscriber, #31383) [Link] (1 responses)

Hi johill,

Patchwork is intended to be independent of git, as other (non-git) projects use patchwork too.

That said, there is a patchwork command-line client, which we use for git integration (eg, set patchwork status to Accepted when a patch is merged).

KS2008: Development tools

Posted Sep 18, 2008 12:20 UTC (Thu) by johill (subscriber, #25196) [Link]

Ok, I guess that makes sense. I'd expected something more integrated in that you can pretty much do all the work with git and don't have to handle the patches "raw" any more. Of course, I guess you can always do something like "patchwork get ppc/235 | git am -" (purely made up.)

KS2008: Development tools

Posted Sep 17, 2008 0:45 UTC (Wed) by jamesh (guest, #1159) [Link] (1 responses)

To do that kind of thing, people need to be sending more than just plain patches.

The equivalent tool that was built to help develop Bazaar is Bundle Buggy. While it can handle plain patches to some extent, it really shines when people send Bazaar bundles which package up all the branch history not present in the target branch.

This means that a developer can merge the branch and pull in all of its history. When this is done, it is trivial to detect when a patch has been merged and remove it from the pending list. If someone posts an updated version of a patch, Bundle Buggy can unambiguously tell that it is derived from a previous patch and mark the old one as obsolete.

The upshot is that the pending list is a fairly accurate representation of what work needs to be merged whether the developers use the web UI or not.

KS2008: Development tools

Posted Sep 18, 2008 12:13 UTC (Thu) by johill (subscriber, #25196) [Link]

Yes, if you can enforce that kind of thing that works well. However, it doesn't really work well in a distributed setting where the users may not all be using the tool itself.

I'm thinking that something as simple as "quilt mail", the git equivalent or whatever should work just fine when everybody adds the right references header etc.

Of course, I'd need to do more thinking, at which point I could probably write a preliminary version of the tool I'm imagining.

KS2008: Development tools

Posted Sep 20, 2008 23:13 UTC (Sat) by ppcpaulus (guest, #45779) [Link]

I don't want patchwork to put the patches into git automatically, because I very often edit the patch description, and occasionally the patch, before putting it into git. Even if the author has provided a decent description, I edit it for stylistic things like making sure the headline starts with "powerpc:" or "powerpc/subsystem:". So it suits me just fine to download the bundle, edit it, and apply it with git am.