* [FFmpeg-devel] forgejo labels
@ 2025-07-28 14:20 Michael Niedermayer
2025-07-28 14:40 ` Diederick C. Niehorster
2025-07-29 21:04 ` Frank Plowman
0 siblings, 2 replies; 9+ messages in thread
From: Michael Niedermayer @ 2025-07-28 14:20 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- 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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [FFmpeg-devel] forgejo labels
2025-07-28 14:20 [FFmpeg-devel] forgejo labels Michael Niedermayer
@ 2025-07-28 14:40 ` Diederick C. Niehorster
2025-07-28 16:15 ` Timo Rothenpieler
2025-07-29 21:04 ` Frank Plowman
1 sibling, 1 reply; 9+ messages in thread
From: Diederick C. Niehorster @ 2025-07-28 14:40 UTC (permalink / raw)
To: FFmpeg development discussions and patches
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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [FFmpeg-devel] forgejo labels
2025-07-28 14:40 ` Diederick C. Niehorster
@ 2025-07-28 16:15 ` Timo Rothenpieler
2025-07-28 17:24 ` Michael Niedermayer
0 siblings, 1 reply; 9+ messages in thread
From: Timo Rothenpieler @ 2025-07-28 16:15 UTC (permalink / raw)
To: ffmpeg-devel
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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [FFmpeg-devel] forgejo labels
2025-07-28 16:15 ` Timo Rothenpieler
@ 2025-07-28 17:24 ` Michael Niedermayer
2025-07-28 17:37 ` Timo Rothenpieler
0 siblings, 1 reply; 9+ messages in thread
From: Michael Niedermayer @ 2025-07-28 17:24 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- 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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [FFmpeg-devel] forgejo labels
2025-07-28 17:24 ` Michael Niedermayer
@ 2025-07-28 17:37 ` Timo Rothenpieler
2025-07-30 5:37 ` Lynne
0 siblings, 1 reply; 9+ messages in thread
From: Timo Rothenpieler @ 2025-07-28 17:37 UTC (permalink / raw)
To: ffmpeg-devel
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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [FFmpeg-devel] forgejo labels
2025-07-28 14:20 [FFmpeg-devel] forgejo labels Michael Niedermayer
2025-07-28 14:40 ` Diederick C. Niehorster
@ 2025-07-29 21:04 ` Frank Plowman
2025-07-29 22:40 ` Michael Niedermayer
1 sibling, 1 reply; 9+ messages in thread
From: Frank Plowman @ 2025-07-29 21:04 UTC (permalink / raw)
To: ffmpeg-devel
[-- 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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [FFmpeg-devel] forgejo labels
2025-07-29 21:04 ` Frank Plowman
@ 2025-07-29 22:40 ` Michael Niedermayer
2025-07-29 23:18 ` Kieran Kunhya via ffmpeg-devel
0 siblings, 1 reply; 9+ messages in thread
From: Michael Niedermayer @ 2025-07-29 22:40 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- 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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [FFmpeg-devel] forgejo labels
2025-07-29 22:40 ` Michael Niedermayer
@ 2025-07-29 23:18 ` Kieran Kunhya via ffmpeg-devel
0 siblings, 0 replies; 9+ messages in thread
From: Kieran Kunhya via ffmpeg-devel @ 2025-07-29 23:18 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Kieran Kunhya
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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [FFmpeg-devel] forgejo labels
2025-07-28 17:37 ` Timo Rothenpieler
@ 2025-07-30 5:37 ` Lynne
0 siblings, 0 replies; 9+ messages in thread
From: Lynne @ 2025-07-30 5:37 UTC (permalink / raw)
To: ffmpeg-devel
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".
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-07-30 5:37 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-07-28 14:20 [FFmpeg-devel] forgejo labels Michael Niedermayer
2025-07-28 14:40 ` Diederick C. Niehorster
2025-07-28 16:15 ` Timo Rothenpieler
2025-07-28 17:24 ` Michael Niedermayer
2025-07-28 17:37 ` Timo Rothenpieler
2025-07-30 5:37 ` Lynne
2025-07-29 21:04 ` Frank Plowman
2025-07-29 22:40 ` Michael Niedermayer
2025-07-29 23:18 ` Kieran Kunhya via ffmpeg-devel
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git