On 14.12.21 21:11, Alexander Kanavin wrote:
What I would like to see at least is correctly tagging patches with dead
upstreams, now that we have the shiny new status for it, and a report
where they can be seen clearly :)
The point of that patch is to have everything more machine readable, so
we can have your requested stats and any stats one can think of :-) -
and to my understanding that was the whole point of defining these
metadata entries.
I think we should head down this road, even if the initial amount of
changes might be quite high - but in the end we might have some pretty
automated, fancy stats, that will really provide some insights.
If we don't, we might end up in defining more and more new ids for
different things already covered by the current approach.
Alex
On Tue, 14 Dec 2021 at 19:48, Konrad Weihmann <kweihm...@outlook.com
<mailto:kweihm...@outlook.com>> wrote:
On 14.12.21 19:38, Bruce Ashfield wrote:
> On Tue, Dec 14, 2021 at 1:05 PM Konrad Weihmann
<kweihm...@outlook.com <mailto:kweihm...@outlook.com>> wrote:
>>
[snip]
>>
>>
meta/recipes-support/vte/vte/0001-Makefile.docs-correctly-substitute-gtkdoc-qemu-wrapp.patch:
>> 6: Upstream-Status: Inappropriate [oe-core specific]
>>
>> or are simply ignoring it at all.
>>
>> In total that are 352 patches I could indentify in latest master.
>>
>> I don't want to open up another can of worms, but either we drop the
>> reasoning from Inappropriate in the patch guideline completely or we
>> need to fix that in core (I guess in other layers it is even
worse :) )
>>
>> Any thoughts?
>
> If we can opt out of the check either in a layer config or a recipe,
> then the noise can at least be minimized. Since the ecosystem !=
> oe-core, this level of checking needs to be something that can be
> opted-out / disabled.
>
> Whatever way this goes, I'd suggest that it not merge until the start
> of the new year .. luckily RP is in full control of when it merges.
>
> Because I for one, won't be spending the Chrismtas holidays queuing
> other people's patches, or fixing status lines in the patches in my
> layers :)
>
> Cheers,
>
> Bruce
Actually a very good idea, but I'm not sure how fine grained we want
these package-qa ids to be... @RP any thoughts?
Basically we can solve the issue either
- by keeping the status quo (dropping the reason from the docu)
- or having is according to docu
- having it as a warning in the first place
- turning it into an error once we are clean in core and
all layers
hosted on yocto project's infra
But yeah sure that patch doesn't need to go in this year, as I don't
want to ruins everyone's holidays :-)
>>
>> On 14.12.21 18:53, Konrad Weihmann wrote:
>>> if a patch uses Upstream-Status: Inappropriate it should
provide a machine
>>> readable reasoning in square brackets.
>>>
>>> According to latest wiki entry that would be
>>>
>>> not author
>>> native
>>> licensing
>>> configuration
>>> enable feature
>>> disable feature
>>> bugfix .*
>>> embedded specific
>>> no upstream
>>> other
>>>
>>> a detailed reasoning could be provided as part of the commit
message,
>>> but format of the metadata line is fixed.
>>>
>>> This patch adds a check to insane.bbclass and warns if there is a
>>> non-compliant reasoning given, or none at all.
>>>
>>> In a follow-up this should be turned into an error, as it was done
>>> with missing Upstream-Status
>>>
>>> Signed-off-by: Konrad Weihmann <kweihm...@outlook.com
<mailto:kweihm...@outlook.com>>
>>> ---
>>> meta/classes/insane.bbclass | 20 ++++++++++++++++++++
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/meta/classes/insane.bbclass
b/meta/classes/insane.bbclass
>>> index 240f3aad62..da26f4662c 100644
>>> --- a/meta/classes/insane.bbclass
>>> +++ b/meta/classes/insane.bbclass
>>> @@ -1191,6 +1191,26 @@ python do_qa_patch() {
>>> bb.error("Malformed Upstream-Status in
patch\n%s\nPlease correct according to %s :\n%s" % (fullpath,
guidelines, match_kinda.group(0)))
>>> else:
>>> bb.error("Missing Upstream-Status in
patch\n%s\nPlease add according to %s ." % (fullpath, guidelines))
>>> +
>>> + inappr_message_re =
r'Inappropriate(\s+\[(?P<reason>.*)\])*'
>>> + inappr_reasons = [
>>> + 'not author',
>>> + 'native',
>>> + 'licensing',
>>> + 'configuration',
>>> + 'enable feature',
>>> + 'disable feature',
>>> + 'bugfix .*',
>>> + 'embedded specific',
>>> + 'no upstream',
>>> + 'other',
>>> + ]
>>> + for match_inappr in re.finditer(inappr_message_re,
content, re.IGNORECASE | re.MULTILINE):
>>> +
>>> + if 'reason' not in match_inappr.groupdict():
>>> + bb.warning("Missing Upstream-Status:
Inappropriate reasoning in patch\n%s\nPlease add according to %s ."
% (fullpath, guidelines))
>>> + elif not any(re.match(x,
match_inappr.groupdict().get('reason', '') or '') for x in
inappr_reasons):
>>> + bb.warning("Malformed Upstream-Status:
Inappropriate in patch\n%s\nPlease correct according to %s :\n%s" %
(fullpath, guidelines, match_inappr.group(0)))
>>> }
>>>
>>> python do_qa_configure() {
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159709):
https://lists.openembedded.org/g/openembedded-core/message/159709
Mute This Topic: https://lists.openembedded.org/mt/87726727/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
