Message ID | 20180419163656.25378-1-vkabatov@redhat.com |
---|---|
Headers | show
Return-Path: <patchwork-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 40Rl576fzbz9s1l for <incoming@patchwork.ozlabs.org>; Fri, 20 Apr 2018 02:37:15 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 40Rl5756nlzF21Z for <incoming@patchwork.ozlabs.org>; Fri, 20 Apr 2018 02:37:15 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com X-Original-To: patchwork@lists.ozlabs.org Delivered-To: patchwork@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=redhat.com (client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=vkabatov@redhat.com; receiver=<UNKNOWN>) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 40Rl511m6rzF1Rl for <patchwork@lists.ozlabs.org>; Fri, 20 Apr 2018 02:37:09 +1000 (AEST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 85DFB40704A9 for <patchwork@lists.ozlabs.org>; Thu, 19 Apr 2018 16:37:06 +0000 (UTC) Received: from vkabatova.usersys.redhat.com (unknown [10.43.17.99]) by smtp.corp.redhat.com (Postfix) with ESMTP id 39CAA84446; Thu, 19 Apr 2018 16:37:06 +0000 (UTC) From: vkabatov@redhat.com To: patchwork@lists.ozlabs.org Subject: [RFC v2 0/1] Rework tagging infrastructure Date: Thu, 19 Apr 2018 18:36:55 +0200 Message-Id: <20180419163656.25378-1-vkabatov@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 19 Apr 2018 16:37:06 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 19 Apr 2018 16:37:06 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'vkabatov@redhat.com' RCPT:'' X-BeenThere: patchwork@lists.ozlabs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Patchwork development <patchwork.lists.ozlabs.org> List-Unsubscribe: <https://lists.ozlabs.org/options/patchwork>, <mailto:patchwork-request@lists.ozlabs.org?subject=unsubscribe> List-Archive: <http://lists.ozlabs.org/pipermail/patchwork/> List-Post: <mailto:patchwork@lists.ozlabs.org> List-Help: <mailto:patchwork-request@lists.ozlabs.org?subject=help> List-Subscribe: <https://lists.ozlabs.org/listinfo/patchwork>, <mailto:patchwork-request@lists.ozlabs.org?subject=subscribe> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: patchwork-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Patchwork" <patchwork-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org> |
Series |
Rework tagging infrastructure
|
expand
|
From: Veronika Kabatova <vkabatov@redhat.com> (TL;DR at the end) This RFC describes an approach to rework tagging. It attempts to solve GitHub issues #57 [1] and #113 [2] as well as some other things we encountered. I'm sending the incomplete version (eg I haven't fixed the tests) to discuss the approach first. Right now, tags are extracted from all the comments on the patch and the patch itself, and they are reextracted from all the sources every time a comment is added or removed. It makes saving slower, and might contribute to races with writes to database when we are parsing multiple emails at the same time. This gets even more prevalent if we want to solve the issue #113 (tags on cover letter should increment counters on every patch in series) -- for each added comment on the cover letter, we would reextract tags from all the other sources, for each patch in series; and for a change on comments related to the patch directly, we would need to take the tags on the cover letter and it's comments into account as well (I implemented this solution in my fork but I really don't like it). The current approach has several other issues as well, some of which are mentioned in the issue #57, eg duplicate tags are counted more times. Taking into account the tags on cover letters would also be easier if we could store tags against them and just query them on demand, instead of reextracting everything all over again. Solutions for some other things we found missing solve the issues mentioned above too. If we want to determine if the tag is duplicate, we need to save the associated value. Having the value would help us to use arbitrary strings as tags (for example links to issue trackers, like `Bugzilla: <link>` if the patch solves a known bug). The key-values approach to storing tags is mentioned [3], this email additionally mentions a comments REST API (currently worked on). For the comments API we would also find it very useful to have the tags extracted from the comments available directly so we can query for them, which means we would either need to reextract the tags on every API call, or we could store the comment data with the tags as they are extracted and only query them as needed. Altogether, we would get rid of the `patch_responses` property used when converting comments to mbox (we finally get all the custom tags there instead of only the few hardcoded ones too). TL;DR: Our goals: - Avoid tag reextraction with each added comment - Fix issues #57 and #113 - Prepare tags addition to comments in the API - Add tags to patch (currently returns {}) and cover letter APIs [1] https://github.com/getpatchwork/patchwork/issues/57 [2] https://github.com/getpatchwork/patchwork/issues/113 [3] https://lists.ozlabs.org/pipermail/patchwork/2018-January/004741.html Veronika Kabatova (1): Rework tagging infrastructure