From owner-svn-ports-all@freebsd.org Tue Jun 25 10:47:38 2019 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BC9D15C8467; Tue, 25 Jun 2019 10:47:38 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ED5784E0E; Tue, 25 Jun 2019 10:47:37 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pl1-x644.google.com with SMTP id e5so8626253pls.13; Tue, 25 Jun 2019 03:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:reply-to:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iqQYyS9Xl59HquyAWjJ44IHjDdncT3qSs3z4f66k6I8=; b=g2rEZEOxCFPS3zrjxcFb4fg3AsnKdO8RKSJRWRhbT+hilPCvYZsdQsCXm63Tloe0g/ 8JLBuHwXkmrS5K1RIdOaOyQSjGPj1mCAxjP5uQwdq3XjtIEodUeTP/wtt3hEujxwiZT1 9zxXvnlCof4wFXgon4+NRfNz1AVSk/PpvloEIB2V8er1uMFeKEVabDUGZ7O/HadS3J8M z3PdCVlfspl/ilsBUep0fItXlES0qGjtk7oHrSdK1ZyQy7imL2z1cV21UsWX7dx6Y7Q3 Ym6JJ0r9EcO4ry+wYx9ayBg0spfjoDtbxOlKHXW2FpJ3AaGySMB6cZMmidRKMcX86abh OSbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=iqQYyS9Xl59HquyAWjJ44IHjDdncT3qSs3z4f66k6I8=; b=L1TUKgnNcX/jf6T1e6enLJ03u4rh58ziM8faXVoVg1CsfCrbCqK4YXdCZ1GVNND6qW SPlP3e0PLr0Sw76RwVVEHGW1cNvYy+b9wNiA3Du7L5Zr1SZyS2c522P3FYam6dKczyyp EL5nc6jkyXrqvWzFLctJaQCF9SKxJNWzz4qWFFte8zfHki7W0EWS39H5R+fFW+XcxU5Y Jfi63akKW6B4VJ38f4h7vUqMTQ6SniqpQ4UhffPgOx2UnDTXmg3mjL5FkKi29jzUFHjz AyCBD7Ts+AXz7uPxlKveFBnQmL8v0ztFIad4Sy6two7O9CnfioACDZB2f7cVTjwLKZRS iv6g== X-Gm-Message-State: APjAAAVR9wGlxUxx0Bmd9NJInT52ABUjh9W3udyPEVq4HSbmM2Ugc52k +MbhO2n8qEwRFcwAIRxTSFt1DxkO X-Google-Smtp-Source: APXvYqyHElmeQNg5znzQyH4Q+aXFXd3VsMkW6hMS/g7WPKHZluiW9GDiADqoisC8mWOr++jbmLy5eQ== X-Received: by 2002:a17:902:7c03:: with SMTP id x3mr129872025pll.242.1561459656384; Tue, 25 Jun 2019 03:47:36 -0700 (PDT) Received: from [192.168.1.103] (180-150-68-130.b49644.syd.nbn.aussiebb.net. [180.150.68.130]) by smtp.gmail.com with ESMTPSA id o16sm13810572pgi.36.2019.06.25.03.47.33 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jun 2019 03:47:35 -0700 (PDT) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: svn commit: r505045 - head/sysutils/plasma5-ksysguard To: =?UTF-8?Q?T=c4=b3l_Coosemans?= Cc: Piotr Kubaj , "Tobias C. Berner" , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org References: <201906241810.x5OIAu1h080487@repo.freebsd.org> <20190624194627.GB49520@ThinkPad-X200.g.anongoth.pl> <20190624202703.GA68048@ThinkPad-X200.g.anongoth.pl> <8eab69dc-52bb-a187-6a30-565ae58f4512@FreeBSD.org> <20190625082911.GA63640@KGPE-D16> <5878f408-2030-7f57-ec1e-5f45e814433f@FreeBSD.org> <20190625120345.0a2cc2eb@kalimero.tijl.coosemans.org> From: Kubilay Kocak Message-ID: <1040f20f-de31-921d-c34c-db6e5bc7de54@FreeBSD.org> Date: Tue, 25 Jun 2019 20:47:31 +1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.0 MIME-Version: 1.0 In-Reply-To: <20190625120345.0a2cc2eb@kalimero.tijl.coosemans.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 6ED5784E0E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.90)[-0.901,0]; TAGGED_FROM(0.00)[] X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 10:47:38 -0000 On 25/06/2019 8:03 pm, Tijl Coosemans wrote: > On Tue, 25 Jun 2019 18:45:33 +1000 Kubilay Kocak > wrote: >> On 25/06/2019 6:29 pm, Piotr Kubaj wrote: >>> To be honest, I fail to see the meaning of this flag. >>> >>> If it's not about approval, then what does this flag actually mean? Only >>> that "I acknowledge that there's a problem"? >> >> It means feedback is required. Feedback can take many forms. Not all >> bugs are patch submissions requiring (only) approval from a maintainer. >> >> Take for example, a bug report without a patch. maintainer-feedback? is >> set when issue is created. The maintainer comes back with 'i can >> reproduce the problem' and sets maintainer-feedback + (feedback >> provided). Triage sets need-patch keyword requesting a patch to fix the >> issue and sets maintainer-feedback? again, feedback this time being in >> the form of a patch. >> >>> Then maybe work-in-progress? As in, the maintainer is working on the fix. >> >> This doesn't cover feedback of forms that don't involve work/patches, >> the vast majority, and this is already covered by needs-patch keyword in >> any case. >> >> Again, if there's any way to improve the maintainer-feedback flag name >> to not mean 'approval' (as thats not what its for), I'd been keen to >> hear ideas. > > But what purpose does it serve? Who's workflow depends on the flag and > why? It all seems like pointless paperwork to me. When maintainer > feedback is necessary seems obvious: if the last comment isn't his, his > feedback is needed. Why do we have to set a flag for that? > for this specific flag, mostly maintainers (by definition), and thereby patch/bug report submitters (or the committers who want to act on an issue, if they are not the same as the submitter). so, basically anyone (@freebsd.org) who wants to action/resolve an issue. Unfortunately "if last comment isn't theirs" doesn't actually work effectively in practice. One needs to know/check who the maintainer is, and one then needs to have read the entire comment thread in its entirety and in context in order to make an informed call that the presence or lack of a comment from the maintainer is actionable in some way. Re why not comments: Because a) its not always clear from comments b) comments aren't explicit nor structured (they cant be searched on, or browsed on), but mostly c) flags set to ? regularly remind the target of that flag that they have a thing they need to action. The context of course to the request is in the name of the flag. It's more useful to consider flags generically, rather than their specific instances currently used, in order to grok their purpose. review? to request review from someone merge? ask someone to merge something (say for releng branches during freeze) needinfo? to ask for info from a specific person (not the maintainer) In particular, and as an example, we could use a needinfo? flag as a way to automate tracking/closing bugs incomplete/feedback timeout, once they reach a certain time period (in the ? state) unacknowledged, say for example, from the original reporter. Anyway, I didn't intend for this to become a deep-dive into issue tracking and workflow. If anyone has ideas on how to name maintainer-feedback more effectively to not (to some) imply its use as an 'approval' mechanic, bugmeister is all ears.