Hi guys, the three issues I have with patch work: 1.) No integration with testing (some machine could apply, build and run make check before I do) 2.) Tracking of patches and not series (we seldomly want a single patch) 3.) No feedback if something has been applied Now Intel[1] seems to have had some of the same concern because: 1.) Their patchwork has a "pull"/"stream" API to wait for changes and execute them. It is in their manual. For us this means we need to somehow figure out where the patch applies to. We can either have the discipline to put this into the subject (git send-email can do it) or we try to see which repository has the specific base commit. It also supports sending back mails with the patch result. 2.) They track series now. 3.) This seems to be unsolved. But we can probably do something ourselves with a little discipline (and in a how-to-contribute documentation). We can use the Change-Id concept that is used by Gerrit. This is a simple local hook that adds a "Change-Id: " line with a unique number. so we will probably end up hosting our own patchwork and try to get intel help/work on 3rd. Could we get a consensus how we know where to apply the patch to? kind regards holger [1] http://damien.lespiau.name/2016/02/augmenting-mailing-lists-with-patchwork.h...
On Mon, Mar 07, 2016 at 10:14:10PM +0100, Holger Freyther wrote:
Could we get a consensus how we know where to apply the patch to?
I had basically the same question when I started in the osmocom code a while back. It was mostly for not having to search around to understand the context. That problem is by now pretty much "fixed", I mostly know what's going on and anyway have a ctags file across all the git repositories to find things easily... The based-on-parent-hash approach sounds like a good solution for robots? But I'm not sure how that works in detail. Are we talking about this? index d9d7390..47f3fa7 100644 It seems to be the hash for the file object, not the parent commit. So one could look for this hash in the git objects database...? It should definitely be something that works automatically, because we *will* forget anything that must be remembered manually. ~Neels -- - Neels Hofmeyr <nhofmeyr@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
On 08 Mar 2016, at 14:12, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote:
On Mon, Mar 07, 2016 at 10:14:10PM +0100, Holger Freyther wrote:
Could we get a consensus how we know where to apply the patch to?
I had basically the same question when I started in the osmocom code a while back. It was mostly for not having to search around to understand the context. That problem is by now pretty much "fixed", I mostly know what's going on and anyway have a ctags file across all the git repositories to find things easily...
I thought we had "From: hash.." or such in git send-email but maybe that was never the case (I wonder how git am -3 patch is implemented then). When using git format-patch there is a from (e.g. From 9b090fd5ab2f6b36a60b41a4f4ac9bd435f18582 Mon Sep 17 00:00:00 2001) but not in the patchwork.. hmm
The based-on-parent-hash approach sounds like a good solution for robots? But I'm not sure how that works in detail. Are we talking about this?
index d9d7390..47f3fa7 100644
It seems to be the hash for the file object, not the parent commit. So one could look for this hash in the git objects database...?
openbsc ich$ git cat-file -t d9d7390 blob so that file is in OpenBSC.. now if the _same_ file is in two repositories we have an issue. :)
It should definitely be something that works automatically, because we *will* forget anything that must be remembered manually.
git config --local format.subjectprefix "libosmocore][PATCH" could be put in the git config of that repository. Sure we will get it wrong once in a while but it might be an alternative. holger
participants (2)
-
Holger Freyther -
Neels Hofmeyr