Date: Tue, 25 Jun 2019 20:47:31 +1000 From: Kubilay Kocak <koobs@FreeBSD.org> To: =?UTF-8?Q?T=c4=b3l_Coosemans?= <tijl@FreeBSD.org> Cc: Piotr Kubaj <pkubaj@anongoth.pl>, "Tobias C. Berner" <tcberner@gmail.com>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r505045 - head/sysutils/plasma5-ksysguard Message-ID: <1040f20f-de31-921d-c34c-db6e5bc7de54@FreeBSD.org> In-Reply-To: <20190625120345.0a2cc2eb@kalimero.tijl.coosemans.org> References: <201906241810.x5OIAu1h080487@repo.freebsd.org> <CAOshKtcPHHa4%2Bv2kL_aNKXzoXs1VkGw0nEAx3PkaArPJ6kCGzw@mail.gmail.com> <20190624194627.GB49520@ThinkPad-X200.g.anongoth.pl> <CAOshKtegUmUYfdnDNmt9wuk1cSC_z_qpz8td597zC4y3Dup_-w@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25/06/2019 8:03 pm, Tijl Coosemans wrote: > On Tue, 25 Jun 2019 18:45:33 +1000 Kubilay Kocak <koobs@FreeBSD.org> > 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 ? <email> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1040f20f-de31-921d-c34c-db6e5bc7de54>