Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Michael Niedermayer <michael@niedermayer.cc>
Subject: [FFmpeg-devel] Re: [RFC] Issue tracker
Date: Tue, 16 Sep 2025 00:36:34 +0200
Message-ID: <20250915223634.GO29660@pb2> (raw)
In-Reply-To: <1298de15-af42-4280-b897-97aadab95087@rothenpieler.org>


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

On Mon, Sep 15, 2025 at 08:35:21PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
> On 9/15/2025 8:26 PM, Michael Niedermayer via ffmpeg-devel wrote:
[...]
> 
> > 
> > > 
> > > Plus the multi-account issue you mentioned.
> > 
> > redmine can accept OAuth2/OIDC logins via plugins IIUC
> > would need to be tested in a test setup but there seems support for shared
> > accounts in principle

> I honestly don't understand the insistence on an external issue tracker.
> That just makes things more complex for no real reason.

It makes things more complex for the admin if there is an external tracker
It makes things easier for the user if there is one tracker instead of 2


> 
> And I also firmly disagree about the current setup being "a mess".
> With no new tickets being allowed on trac, its quite the opposite of that.
> If issues/tickets could be opened on both, then it'd be a mess.
> This way it's just a migration.

simple example. To show a few things that could happen

A user found 2 bugs in the svq1 decoder, what does she do now ?

Before she has to
1. search trac for bugs in the svq1 decoder, she finds the first bug there with two
proposed patches but no sample
2. she registers on trac
3. she uploads the sample and confirms that the first patch fixes it
4. she opens a new report for bug #2

But now after trac->forgejo she has to
1. search trac for bugs in the svq1 decoder, she finds the first bug there with a
proposed patch but no sample
2. she registers on trac
3. she uploads the sample and confirms that the patch fixes it
4. she tries to open a new ticket, but she is redirected to Forgejo
5. she registers on forgejo
6. she searches for the 2 bugs on forgejo, she finds a duplicate of #1
   it links to a unrelated issue on trac or links to none and has been closed and a patch
   which doesnt fix the issue was applied already. A mistake that happened because
   the earlier patch in trac was missed
7. she uploads the sample to forgejo too
8. she reopens the duplicate issue and adds a link to trac explaining that
   the fix in trac was correct. People are confused and just ignore the ticket
   the wrong fix also isnt reverted as noone realized that a wrong fix was applied
   already
9. she searches for the 2nd issue and also doesnt find it on forgejo
10.she opens a issue on forgejo for the 2nd issue
11. she is being asked to please check for duplicates on trac
12. she repeatedly searched trac for the issue and
13. she replies explaining she checked twice and thats a new issue

Its a constructed example but its quite a bit of extra work for everyone
and the outcome in the example is worse, as confusion and mistakes
have lead to the application of a wrong patch


> 
> And the tickets on trac won't go away, so no history will be lost.


> If you really want, I can import them all into Forgejo, but _that_ will be
> horribly messy.

It is largely just basic text with minimal formating, why does this
become messy ?

can we do something about the messyness and have this "not messy" ?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell

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

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

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

      parent reply	other threads:[~2025-09-15 22:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-14 21:23 [FFmpeg-devel] " Michael Niedermayer via ffmpeg-devel
2025-09-15 11:09 ` [FFmpeg-devel] " Michael Niedermayer via ffmpeg-devel
2025-09-15 11:37   ` Michael Niedermayer via ffmpeg-devel
2025-09-15 12:06   ` Timo Rothenpieler via ffmpeg-devel
2025-09-15 12:30     ` Michael Niedermayer via ffmpeg-devel
2025-09-15 12:47       ` Timo Rothenpieler via ffmpeg-devel
2025-09-15 12:57     ` Michael Niedermayer via ffmpeg-devel
2025-09-15 13:05       ` Michael Niedermayer via ffmpeg-devel
2025-09-15 17:19       ` Timo Rothenpieler via ffmpeg-devel
2025-09-15 18:26         ` Michael Niedermayer via ffmpeg-devel
2025-09-15 18:35           ` Timo Rothenpieler via ffmpeg-devel
2025-09-15 19:09             ` Gyan Doshi via ffmpeg-devel
2025-09-15 21:46               ` Michael Niedermayer via ffmpeg-devel
2025-09-16  4:39                 ` Gyan Doshi via ffmpeg-devel
2025-09-15 22:36             ` Michael Niedermayer via ffmpeg-devel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250915223634.GO29660@pb2 \
    --to=ffmpeg-devel@ffmpeg.org \
    --cc=michael@niedermayer.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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