svn commit: r505045 - head/sysutils/plasma5-ksysguard

[Kubilay Kocak]

On 25/06/2019 8:03 pm, Tijl Coosemans wrote:
> On Tue, 25 Jun 2019 18:45:33 +1000 Kubilay Kocak <koobs at 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.