svn commit: r505045 - head/sysutils/plasma5-ksysguard
Kubilay Kocak
koobs at FreeBSD.org
Tue Jun 25 08:45:39 UTC 2019
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.
> On 19-06-25 11:59:32, Kubilay Kocak wrote:
>> On 25/06/2019 6:27 am, Piotr Kubaj wrote:
>>> OK, for me maintainer-feedback entry means that the patch is accepted.
>>>
>>> When I wasn't a committer, I used to set maintainer-feedback to indicate
>>> that I accept the patch. When I send PR's nowadays, some maintainers
>>> also do that.
>>>
>>> On 19-06-24 21:54:56, Tobias C. Berner wrote:
>>>> I set maintainer feedback, because I, as the maintainer gave you the
>>>> feedback, that "I think this is wrong" :)
>>>> If I liked that patch, I would have set the patch-approved flag on it.
>>>>
>>>>
>>>> All that said, thanks for "fixing" it, but I still would prefer a real
>>>> fix,
>>>> that we can upstream rather than that.
>>>>
>>>>
>>>> mfg Tobias
>>>>
>>>>
>>>> On Mon, 24 Jun 2019 at 21:46, Piotr Kubaj <pkubaj at anongoth.pl> wrote:
>>>>
>>>>> Oh, I didn't use "implicit". Doesn't maintainer-feedback + mean that
>>>>> it's
>>>>> accepted?
>>>>>
>>>>> On 19-06-24 21:34:09, Tobias C. Berner wrote:
>>>>> >Moin moin
>>>>> >
>>>>> >Sorry, but I explicitely did not approve this :) so using implicit
>>>>> on it,
>>>>> >is a bit of a crappy move.
>>>>> >
>>>>> >mfg Tobias
>>>>> >
>>>>> >On Mon, 24 Jun 2019 at 20:11, Piotr Kubaj <pkubaj at freebsd.org> wrote:
>>>>> >
>>>>> >> Author: pkubaj
>>>>> >> Date: Mon Jun 24 18:10:55 2019
>>>>> >> New Revision: 505045
>>>>> >> URL: https://svnweb.freebsd.org/changeset/ports/505045
>>>>> >>
>>>>> >> Log:
>>>>> >> sysutils/plasma5-ksysguard: fix build with GCC-based
>>>>> architectures
>>>>> >>
>>>>> >> Link with libinotify explicitly to fix linking on GCC
>>>>> architectures.
>>>>> >>
>>>>> >> PR: 238702
>>>>> >> Approved by: tcberner (maintainer, mentor)
>>>>> >>
>>>>> >> Modified:
>>>>> >> head/sysutils/plasma5-ksysguard/Makefile
>>>>> >>
>>>>> >> Modified: head/sysutils/plasma5-ksysguard/Makefile
>>>>> >>
>>>>> >>
>>>>> ==============================================================================
>>>>>
>>>>>
>>>>> >> --- head/sysutils/plasma5-ksysguard/Makefile Mon Jun 24
>>>>> 18:07:12 2019
>>>>> >> (r505044)
>>>>> >> +++ head/sysutils/plasma5-ksysguard/Makefile Mon Jun 24
>>>>> 18:10:55 2019
>>>>> >> (r505045)
>>>>> >> @@ -23,5 +23,6 @@ OPTIONS_SUB= yes
>>>>> >>
>>>>> >> INOTIFY_DESC= Filesystem alteration notifications using
>>>>> inotify
>>>>> >> INOTIFY_LIB_DEPENDS= libinotify.so:devel/libinotify
>>>>> >> +INOTIFY_LDFLAGS= -linotify
>>>>> >>
>>>>> >> .include <bsd.port.mk>
>>
>>
>> What could we (bugmeister) name the flag so that it was clear that
>>
>> a) The flag is about needing feedback
>> b) The flag has nothing to do with / does not mean approval?
>>
>>
More information about the svn-ports-all
mailing list