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

Piotr Kubaj pkubaj at anongoth.pl
Tue Jun 25 09:13:17 UTC 2019


OK then, I get the meaning of this flag now.

Still, it would be good if you could post some FAQ on bugzilla so that others know too :)

On 19-06-25 18:45:33, 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.
>
>
>> 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?
>>>
>>>
>
>
>
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20190625/2ea0c9c8/attachment.sig>


More information about the svn-ports-all mailing list