[FFmpeg-devel] forgejo labels

[FFmpeg-devel] forgejo labels

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 612 bytes --]

Hi

regression: issue aaddresses a regression
bug:        something is not working

This is inconsistent
Label X cannot sometimes mean "X is removed" and "X is added"

bug seems meaning that the PR adds a bug
regression seems meaning that the PR removes a regression

IMO this should be done consistently
a PR can have bugs and it can fix bugs
a PR can cause regressions and it can fix regressions

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] forgejo labels

[Diederick C. Niehorster]

On Mon, Jul 28, 2025 at 4:21 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Hi
>
> regression: issue aaddresses a regression
> bug:        something is not working
>
> This is inconsistent
> Label X cannot sometimes mean "X is removed" and "X is added"
>
> bug seems meaning that the PR adds a bug
> regression seems meaning that the PR removes a regression
>
> IMO this should be done consistently
> a PR can have bugs and it can fix bugs
> a PR can cause regressions and it can fix regressions

so lets rename the labels to bug_fix, regression_fix and add has_bug
and has_regression. The former two colored green, the latter two
colored red.

Issues also need labels, and there "bug" and "regression" are fine,
indicating that an issue flags a bug instead of, e.g., a feature
request (and applying bug+regression makes sense).

All the best,
Dee
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] forgejo labels

[Timo Rothenpieler]

On 7/28/2025 4:40 PM, Diederick C. Niehorster wrote:
> On Mon, Jul 28, 2025 at 4:21 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
>>
>> Hi
>>
>> regression: issue aaddresses a regression
>> bug:        something is not working
>>
>> This is inconsistent
>> Label X cannot sometimes mean "X is removed" and "X is added"
>>
>> bug seems meaning that the PR adds a bug
>> regression seems meaning that the PR removes a regression
>>
>> IMO this should be done consistently
>> a PR can have bugs and it can fix bugs
>> a PR can cause regressions and it can fix regressions
> 
> so lets rename the labels to bug_fix, regression_fix and add has_bug
> and has_regression. The former two colored green, the latter two
> colored red.
> 
> Issues also need labels, and there "bug" and "regression" are fine,
> indicating that an issue flags a bug instead of, e.g., a feature
> request (and applying bug+regression makes sense).

Every PR is also an issue, labels apply to both.
So for an issue, the label would imply that it reports a bug or 
regression, and for a PR that it fixes it respectively.

Having two split labels for that seems a little unnecessary.

Or we could just not use the bug/regession label on PRs, cause they do 
seem kinda off there.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] forgejo labels

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1623 bytes --]

On Mon, Jul 28, 2025 at 06:15:53PM +0200, Timo Rothenpieler wrote:
> On 7/28/2025 4:40 PM, Diederick C. Niehorster wrote:
> > On Mon, Jul 28, 2025 at 4:21 PM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > > 
> > > Hi
> > > 
> > > regression: issue aaddresses a regression
> > > bug:        something is not working
> > > 
> > > This is inconsistent
> > > Label X cannot sometimes mean "X is removed" and "X is added"
> > > 
> > > bug seems meaning that the PR adds a bug
> > > regression seems meaning that the PR removes a regression
> > > 
> > > IMO this should be done consistently
> > > a PR can have bugs and it can fix bugs
> > > a PR can cause regressions and it can fix regressions
> > 
> > so lets rename the labels to bug_fix, regression_fix and add has_bug
> > and has_regression. The former two colored green, the latter two
> > colored red.

This sounds reasonable


[...]

> So for an issue, the label would imply that it reports a bug or regression,
> and for a PR that it fixes it respectively.
> 

> Having two split labels for that seems a little unnecessary.

I dont know, i have only used forgejo for a few days


> 
> Or we could just not use the bug/regession label on PRs, cause they do seem
> kinda off there.

thats reasonable too, but it probably should then also not be possible to
select them.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] forgejo labels

[Timo Rothenpieler]

On 7/28/2025 7:24 PM, Michael Niedermayer wrote:
> On Mon, Jul 28, 2025 at 06:15:53PM +0200, Timo Rothenpieler wrote:
>> On 7/28/2025 4:40 PM, Diederick C. Niehorster wrote:
>>> On Mon, Jul 28, 2025 at 4:21 PM Michael Niedermayer
>>> <michael@niedermayer.cc> wrote:
>>>>
>>>> Hi
>>>>
>>>> regression: issue aaddresses a regression
>>>> bug:        something is not working
>>>>
>>>> This is inconsistent
>>>> Label X cannot sometimes mean "X is removed" and "X is added"
>>>>
>>>> bug seems meaning that the PR adds a bug
>>>> regression seems meaning that the PR removes a regression
>>>>
>>>> IMO this should be done consistently
>>>> a PR can have bugs and it can fix bugs
>>>> a PR can cause regressions and it can fix regressions
>>>
>>> so lets rename the labels to bug_fix, regression_fix and add has_bug
>>> and has_regression. The former two colored green, the latter two
>>> colored red.
> 
> This sounds reasonable
> 
> 
> [...]
> 
>> So for an issue, the label would imply that it reports a bug or regression,
>> and for a PR that it fixes it respectively.
>>
> 
>> Having two split labels for that seems a little unnecessary.
> 
> I dont know, i have only used forgejo for a few days

This is purely convention we want to use, there's no established 
standard for that. Practically every project does something slightly 
different.

>>
>> Or we could just not use the bug/regession label on PRs, cause they do seem
>> kinda off there.
> 
> thats reasonable too, but it probably should then also not be possible to
> select them.

That is not an option, Labels apply to all issues, including PRs.
Probably a valid feature request to post.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] forgejo labels

[Lynne]

On 29/07/2025 02:37, Timo Rothenpieler wrote:
> On 7/28/2025 7:24 PM, Michael Niedermayer wrote:
>> On Mon, Jul 28, 2025 at 06:15:53PM +0200, Timo Rothenpieler wrote:
>>> On 7/28/2025 4:40 PM, Diederick C. Niehorster wrote:
>>>> On Mon, Jul 28, 2025 at 4:21 PM Michael Niedermayer
>>>> <michael@niedermayer.cc> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> regression: issue aaddresses a regression
>>>>> bug:        something is not working
>>>>>
>>>>> This is inconsistent
>>>>> Label X cannot sometimes mean "X is removed" and "X is added"
>>>>>
>>>>> bug seems meaning that the PR adds a bug
>>>>> regression seems meaning that the PR removes a regression
>>>>>
>>>>> IMO this should be done consistently
>>>>> a PR can have bugs and it can fix bugs
>>>>> a PR can cause regressions and it can fix regressions
>>>>
>>>> so lets rename the labels to bug_fix, regression_fix and add has_bug
>>>> and has_regression. The former two colored green, the latter two
>>>> colored red.
>>
>> This sounds reasonable
>>
>>
>> [...]
>>
>>> So for an issue, the label would imply that it reports a bug or 
>>> regression,
>>> and for a PR that it fixes it respectively.
>>>
>>
>>> Having two split labels for that seems a little unnecessary.
>>
>> I dont know, i have only used forgejo for a few days
> 
> This is purely convention we want to use, there's no established 
> standard for that. Practically every project does something slightly 
> different.
> 
>>>
>>> Or we could just not use the bug/regession label on PRs, cause they 
>>> do seem
>>> kinda off there.
>>
>> thats reasonable too, but it probably should then also not be possible to
>> select them.
> 
> That is not an option, Labels apply to all issues, including PRs.
> Probably a valid feature request to post.
Could you at least rename issue/bug and issue/regression to just bug and 
regression?
A bug is an issue, and a regression is also an issue. Its very redundant.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] forgejo labels

[Frank Plowman]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 623 bytes --]

On 28/07/2025 15:20, Michael Niedermayer wrote:
> Hi
> 
> regression: issue aaddresses a regression
> bug:        something is not working
> 
> This is inconsistent
> Label X cannot sometimes mean "X is removed" and "X is added"
> 
> bug seems meaning that the PR adds a bug
> regression seems meaning that the PR removes a regression
> 
> IMO this should be done consistently
> a PR can have bugs and it can fix bugs
> a PR can cause regressions and it can fix regressions
> 
> thx
> 

Slightly tangential, but labels to say "this fix should be backported to
release X" would be useful.

-- 
Frank

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 1091 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] forgejo labels

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1298 bytes --]

On Tue, Jul 29, 2025 at 10:04:51PM +0100, Frank Plowman wrote:
> On 28/07/2025 15:20, Michael Niedermayer wrote:
> > Hi
> > 
> > regression: issue aaddresses a regression
> > bug:        something is not working
> > 
> > This is inconsistent
> > Label X cannot sometimes mean "X is removed" and "X is added"
> > 
> > bug seems meaning that the PR adds a bug
> > regression seems meaning that the PR removes a regression
> > 
> > IMO this should be done consistently
> > a PR can have bugs and it can fix bugs
> > a PR can cause regressions and it can fix regressions
> > 
> > thx
> > 
> 
> Slightly tangential, but labels to say "this fix should be backported to
> release X" would be useful.

A label thats added by a human
A label that a human must search for
A label that a human must clear after a commit is backported

is not usefull

A system that on a single click shows a list of
commit hashes that have not yet been backported
and once a commit is backported it automtaically disappears from
the list, can be usefull.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] forgejo labels

[Kieran Kunhya via ffmpeg-devel]

On Tue, Jul 29, 2025 at 11:40 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> On Tue, Jul 29, 2025 at 10:04:51PM +0100, Frank Plowman wrote:
> > On 28/07/2025 15:20, Michael Niedermayer wrote:
> > > Hi
> > >
> > > regression: issue aaddresses a regression
> > > bug:        something is not working
> > >
> > > This is inconsistent
> > > Label X cannot sometimes mean "X is removed" and "X is added"
> > >
> > > bug seems meaning that the PR adds a bug
> > > regression seems meaning that the PR removes a regression
> > >
> > > IMO this should be done consistently
> > > a PR can have bugs and it can fix bugs
> > > a PR can cause regressions and it can fix regressions
> > >
> > > thx
> > >
> >
> > Slightly tangential, but labels to say "this fix should be backported to
> > release X" would be useful.
>
> A label thats added by a human
> A label that a human must search for
> A label that a human must clear after a commit is backported
>
> is not usefull
>
> A system that on a single click shows a list of
> commit hashes that have not yet been backported
> and once a commit is backported it automtaically disappears from
> the list, can be usefull.

You can do that by making a MR between the two branches:
https://code.ffmpeg.org/kierank/FFmpeg/compare/release/7.1...master

Kieran
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".