[FFmpeg-devel] [RFC] Issue tracker

[FFmpeg-devel] [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi everyone

trac supports, custom search queries, customly formated results

People can vote on tickets, we can have custom ticket states and custom
workflow on tickets.

Are these things possible in forgejo ?

For example, what we use in trac:

Open Tickets ordered by number of votes colored based on priorty
https://trac.ffmpeg.org/report/11

Non Developer tickets:
https://trac.ffmpeg.org/report/15

Open and New tickets sorted by priority:
https://trac.ffmpeg.org/report/1

Closed Tickts showing the resolution (needs_more_info, fixed, invalid, wontfix) sorted by last modification:
https://trac.ffmpeg.org/query?status=closed&order=changetime&desc=1&col=id&col=summary&col=type&col=component&col=resolution&col=changetime

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some people wanted to paint the bikeshed green, some blue and some pink.
People argued and fought, when they finally agreed, only rust was left.

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi all

ATM the bug reporting guidlines point to trac
and https://trac.ffmpeg.org/newticket redirects to forgejo

So if a user found a bug, now what does she do?
1. First she (maybe) looks at the bug reporting guidlines (which point to trac)
2. and she registers on trac
3. she maybe searches for existing tickets on trac, and maybe adds her info there
4. she tries to open a new ticket on trac and gets redirected to forgejo
5a. she refuses to register on a 2nd tracker and leaves
5b. she registers on forgejo
6. she searches for an existing report on forgejo and maybe adds her bug info there
7. she opens a new ticket on forgejo

lets summarize, what is wrong here
0. I think many people are/where unaware of the newticket redirect (I was unaware until very recently)
1. I think some of the consequences of this regirect where missed
2. the bug tracker was half switched to forgejo
3. users have to register on 2 trackers (they may need to add comments on either)
4. users have to search bugs on 2 trackers (both if they want to open a new one and also
    if they are just looking for one)
5. forgejo lacks some nice features like searching per number of votes

So what are we going to do now ?
T. Undo the half move and stay with trac, move or loose 61+32 tickets from forgejo to trac
F. Fully move from trac to forgejo, move 3176+8501 tickets from trac to forgejo
D. have some tickets in trac and some in forgejo, require users to register and search both
?. something else ?


Ideas, Comments ?

thx


On Sun, Sep 14, 2025 at 11:23:17PM +0200, Michael Niedermayer via ffmpeg-devel wrote:
> Hi everyone
> 
> trac supports, custom search queries, customly formated results
> 
> People can vote on tickets, we can have custom ticket states and custom
> workflow on tickets.
> 
> Are these things possible in forgejo ?
> 
> For example, what we use in trac:
> 
> Open Tickets ordered by number of votes colored based on priorty
> https://trac.ffmpeg.org/report/11
> 
> Non Developer tickets:
> https://trac.ffmpeg.org/report/15
> 
> Open and New tickets sorted by priority:
> https://trac.ffmpeg.org/report/1
> 
> Closed Tickts showing the resolution (needs_more_info, fixed, invalid, wontfix) sorted by last modification:
> https://trac.ffmpeg.org/query?status=closed&order=changetime&desc=1&col=id&col=summary&col=type&col=component&col=resolution&col=changetime
> 
> thx
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Some people wanted to paint the bikeshed green, some blue and some pink.
> People argued and fought, when they finally agreed, only rust was left.



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


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

On Mon, Sep 15, 2025 at 01:09:47PM +0200, Michael Niedermayer via ffmpeg-devel wrote:
> Hi all
> 
> ATM the bug reporting guidlines point to trac
> and https://trac.ffmpeg.org/newticket redirects to forgejo
> 
> So if a user found a bug, now what does she do?
> 1. First she (maybe) looks at the bug reporting guidlines (which point to trac)
> 2. and she registers on trac
> 3. she maybe searches for existing tickets on trac, and maybe adds her info there
> 4. she tries to open a new ticket on trac and gets redirected to forgejo
> 5a. she refuses to register on a 2nd tracker and leaves
> 5b. she registers on forgejo
> 6. she searches for an existing report on forgejo and maybe adds her bug info there
> 7. she opens a new ticket on forgejo
> 
> lets summarize, what is wrong here
> 0. I think many people are/where unaware of the newticket redirect (I was unaware until very recently)
> 1. I think some of the consequences of this regirect where missed
> 2. the bug tracker was half switched to forgejo
> 3. users have to register on 2 trackers (they may need to add comments on either)
> 4. users have to search bugs on 2 trackers (both if they want to open a new one and also
>     if they are just looking for one)
> 5. forgejo lacks some nice features like searching per number of votes
> 
> So what are we going to do now ?
> T. Undo the half move and stay with trac, move or loose 61+32 tickets from forgejo to trac
> F. Fully move from trac to forgejo, move 3176+8501 tickets from trac to forgejo
> D. have some tickets in trac and some in forgejo, require users to register and search both
> ?. something else ?
> 
> 
> Ideas, Comments ?

Some brainstorming, potential steps that someone may need to do

for T,
    phase 0:
     + forgejos new ticket page should redirect to trac instead of trac to forgejo
       or the page should explain the use of forgejo vs trac
    phase 1
     + some or all of the 93 tickets should be moved to trac
       (if all then forgejos issue tracker can be disabled)
    phase 2:
     + we need to investigate some scalability issues. We have one admin page
       that takes a really long time to load. It sometimes times out but seems
       working ATM. But as users, tickets and sessions grow we will likely at
       some point become unable to load this page without increasing timeouts
       at webserver and browser. Timo has already spend time on
       updating things, switching database and so on. So really solving this,
       may involve becoming active in development on trac itself

for F,
    phase 0:
     + bugreporting guide needs update
     + tracs new ticket page should explain the transition and link to forgejo
       not just redirect (it confuses users especially if the bugreporting guide just
       pointed them to trac)
    phase 1:
     + 11696 tickets need to be moved into forgejo with their metadata (creation
       date, authors, comments, state, resolution, number, keywords, html and git links,
       CC, attachments) or we need to accept to loose this data in a searchable way
     + keywords -> labels ?
     + per ticket redirects to forgejo
    phase 2:
     + wiki needs to be transitioned to forgejo, ideally with history or we need
       to keep the wiki in trac and disable in forgejo
     + per wiki page redirects to forgejo
    phase 3:
     + trac shutdown
     + landing page (register & new) redirect to forgejo

    note, we also serve trac.mplayerhq.hu

for D,
    + bugreporting guide needs update
    + both trackers search and register pages need to point to the other too
      so the users know that they need to search both trackers
    + or hire some web UI developer and have her write a meta search
      that searches both trakers

thx


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Timo Rothenpieler via ffmpeg-devel]

On 15/09/2025 13:09, Michael Niedermayer via ffmpeg-devel wrote:
> Hi all
> 
> ATM the bug reporting guidlines point to trac
> and https://trac.ffmpeg.org/newticket redirects to forgejo
> 
> So if a user found a bug, now what does she do?
> 1. First she (maybe) looks at the bug reporting guidlines (which point to trac)
> 2. and she registers on trac
> 3. she maybe searches for existing tickets on trac, and maybe adds her info there
> 4. she tries to open a new ticket on trac and gets redirected to forgejo
> 5a. she refuses to register on a 2nd tracker and leaves
> 5b. she registers on forgejo
> 6. she searches for an existing report on forgejo and maybe adds her bug info there
> 7. she opens a new ticket on forgejo
> 
> lets summarize, what is wrong here
> 0. I think many people are/where unaware of the newticket redirect (I was unaware until very recently)
> 1. I think some of the consequences of this regirect where missed
> 2. the bug tracker was half switched to forgejo
> 3. users have to register on 2 trackers (they may need to add comments on either)
> 4. users have to search bugs on 2 trackers (both if they want to open a new one and also
>      if they are just looking for one)
> 5. forgejo lacks some nice features like searching per number of votes
> 
> So what are we going to do now ?
> T. Undo the half move and stay with trac, move or loose 61+32 tickets from forgejo to trac
> F. Fully move from trac to forgejo, move 3176+8501 tickets from trac to forgejo
> D. have some tickets in trac and some in forgejo, require users to register and search both
> ?. something else ?
> 
> 
> Ideas, Comments ?

I do think trac is a dead end software, and we want to eventually retire it.
It can stick around in read-only mode indefinitely, eventually turned 
into a dump of static HTML pages. But it's not a software that we can 
keep supporting forever.

I thought Forgejo had votes as well, but I can't find them anymore, so I 
might be misremembering that.
But the usual issue conclusions are represented via labels, and they do 
exist. And have been used for that purpose already.
Not sure I'd really want to stick with hard to maintain trac just for 
voting on issues. If we really want that, it'd probably easier to 
contribute that feature to Forgejo.

I'm also not a fan of migrating issues, since the migrates one are 
always going to be horribly ugly, basically just consisting of one big 
quote posted by a bot account.
It is possible to do though, so if that's desired instead of keeping 
trac itself around, I can look into it.

So my preferred solution is to just keep the two separated, disable new 
tickets on trac, and at some point in the distant future make trac fully 
read-only/turn it into static HTML pages.

Forgejo already back-references trac issues when they're tagged 
somewhere on the FFmpeg/FFmpeg repo, hence all the new issues/PRs start 
at 20000.
If we really kept using trac that would also eventually clash and then 
really make a huge mess.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi

On Mon, Sep 15, 2025 at 02:06:07PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
[...]

> 
> I thought Forgejo had votes as well, but I can't find them anymore, so I
> might be misremembering that.

One can add thumbs up and down to individual messages of an issue but they
are not shown in the search results or searchable as far as i can see

In fact the whole search capability in Forgejo is disappointing
even searching for open (not new) tickets doesnt work as documented
(one cannot disable "new" lables by alt + mouse click it works by
 alt + keyboard click)


> But the usual issue conclusions are represented via labels, and they do
> exist. And have been used for that purpose already.
> Not sure I'd really want to stick with hard to maintain trac just for voting
> on issues. If we really want that, it'd probably easier to contribute that
> feature to Forgejo.
> 

> I'm also not a fan of migrating issues, since the migrates one are always
> going to be horribly ugly, basically just consisting of one big quote posted
> by a bot account.
> It is possible to do though, so if that's desired instead of keeping trac
> itself around, I can look into it.

Naively, i would have thought that issue migration would be done by a
Database -> Database thing

but there are many shades of this

one could leave issues in trac and instead extend Forgejos search so it
simply in addition to what it does also have it run a sql querry
in the trac db and simply return links to the trac tickets

this actually feels like quite doable for someone knowing Forgejo
and also the trac db layout. (that is not me)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Timo Rothenpieler via ffmpeg-devel]

On 15/09/2025 14:30, Michael Niedermayer via ffmpeg-devel wrote:
> Hi
> 
> On Mon, Sep 15, 2025 at 02:06:07PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
> [...]
> 
>>
>> I thought Forgejo had votes as well, but I can't find them anymore, so I
>> might be misremembering that.
> 
> One can add thumbs up and down to individual messages of an issue but they
> are not shown in the search results or searchable as far as i can see
> 
> In fact the whole search capability in Forgejo is disappointing
> even searching for open (not new) tickets doesnt work as documented
> (one cannot disable "new" lables by alt + mouse click it works by
>   alt + keyboard click)
> 
> 
>> But the usual issue conclusions are represented via labels, and they do
>> exist. And have been used for that purpose already.
>> Not sure I'd really want to stick with hard to maintain trac just for voting
>> on issues. If we really want that, it'd probably easier to contribute that
>> feature to Forgejo.
>>
> 
>> I'm also not a fan of migrating issues, since the migrates one are always
>> going to be horribly ugly, basically just consisting of one big quote posted
>> by a bot account.
>> It is possible to do though, so if that's desired instead of keeping trac
>> itself around, I can look into it.
> 
> Naively, i would have thought that issue migration would be done by a
> Database -> Database thing

Yeah, that's how I'd do it as well. But every actual reply to an issue 
needs to be associated to a user, and spamming our user DB with 
thousands of users just for the migration isn't great.

> but there are many shades of this
> 
> one could leave issues in trac and instead extend Forgejos search so it
> simply in addition to what it does also have it run a sql querry
> in the trac db and simply return links to the trac tickets

I doubt Forgejo would accept that as a contribution, and I do not really 
want to start maintaining a fork of Forgejo for our instance.

> this actually feels like quite doable for someone knowing Forgejo
> and also the trac db layout. (that is not me)

It'd need to be done in some generic way so that any arbitrary issue 
tracker can be hooked up like that. So it's quite a bit of work.

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

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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi

On Mon, Sep 15, 2025 at 02:06:07PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
> On 15/09/2025 13:09, Michael Niedermayer via ffmpeg-devel wrote:
[...]
> > Ideas, Comments ?
> 
> I do think trac is a dead end software, and we want to eventually retire it.

btw, anyone knows why the trac project seems dieing / dead ?
Its a quite capable issue tracker ...

also how is it related to redmine, which seems to have some support
for importing trac ?

Have we considered redmine as alternative ?
If we could do a full import of trac, this may be a smoother

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

On Mon, Sep 15, 2025 at 02:57:53PM +0200, Michael Niedermayer via ffmpeg-devel wrote:
> Hi
> 
> On Mon, Sep 15, 2025 at 02:06:07PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
> > On 15/09/2025 13:09, Michael Niedermayer via ffmpeg-devel wrote:
> [...]
> > > Ideas, Comments ?
> > 
> > I do think trac is a dead end software, and we want to eventually retire it.
> 
> btw, anyone knows why the trac project seems dieing / dead ?
> Its a quite capable issue tracker ...
> 
> also how is it related to redmine, which seems to have some support
> for importing trac ?
> 
> Have we considered redmine as alternative ?

> If we could do a full import of trac, this may be a smoother

smoother solution (iam missing words in my sentances)


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Timo Rothenpieler via ffmpeg-devel]

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

On 9/15/2025 2:57 PM, Michael Niedermayer via ffmpeg-devel wrote:
> Hi
> 
> On Mon, Sep 15, 2025 at 02:06:07PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
>> On 15/09/2025 13:09, Michael Niedermayer via ffmpeg-devel wrote:
> [...]
>>> Ideas, Comments ?
>>
>> I do think trac is a dead end software, and we want to eventually retire it.
> 
> btw, anyone knows why the trac project seems dieing / dead ?
> Its a quite capable issue tracker ...
> 
> also how is it related to redmine, which seems to have some support
> for importing trac ?
> 
> Have we considered redmine as alternative ?
> If we could do a full import of trac, this may be a smoother

redmine is apparently a "trac clone written in ruby".
No idea if it's database-compatible, or just similar idea but full 
re-implementation.

But really, I don't see how in the long run a separate issue tracker 
from Forgejo makes sense.
The issue IDs will eventually clash, and integration and linking between 
them will be a right mess.

Plus the multi-account issue you mentioned.

I never had issues with the Forgejo Issue search. What exactly is 
broken/missing? Fixing/enhancing those things is usually pretty easy.

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4742 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi Timo

On Mon, Sep 15, 2025 at 07:19:17PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
> On 9/15/2025 2:57 PM, Michael Niedermayer via ffmpeg-devel wrote:
> > Hi
> > 
> > On Mon, Sep 15, 2025 at 02:06:07PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
> > > On 15/09/2025 13:09, Michael Niedermayer via ffmpeg-devel wrote:
> > [...]
> > > > Ideas, Comments ?
> > > 
> > > I do think trac is a dead end software, and we want to eventually retire it.
> > 
> > btw, anyone knows why the trac project seems dieing / dead ?
> > Its a quite capable issue tracker ...
> > 
> > also how is it related to redmine, which seems to have some support
> > for importing trac ?
> > 
> > Have we considered redmine as alternative ?
> > If we could do a full import of trac, this may be a smoother
> 
> redmine is apparently a "trac clone written in ruby".
> No idea if it's database-compatible, or just similar idea but full
> re-implementation.
> 

> But really, I don't see how in the long run a separate issue tracker from
> Forgejo makes sense.
> The issue IDs will eventually clash, and integration and linking between
> them will be a right mess.

the mix of trac and Forgejo is already a mess if theres no _clean_
way to import the tickets
We would always have 15 years of ticket history outside our issue tracker

if you really want to have pull requests and issues have distinct positive numbers
well, make one even and the other odd above the value where they would clash
so it would be
0..20k Trac
20k-25k Forgejo
25k+ even Forgejo
25k+ odd redmine


> 
> 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 never had issues with the Forgejo Issue search. What exactly is
> broken/missing? Fixing/enhancing those things is usually pretty easy.

1. It doesnt show the number of thumbs up / down in the search result
2. I cannot sort based on the thumbs up / down
3. on the labels it says "Use Alt + Click to exclude labels", this does not work
   alt-shift-click works, alt click doesnt, alt-enter works
   it may be that alt-click is interpreted by browser or by some other component
   but either way it doesnt work, the user will not care why it doesnt work, its
   bad UI
4. it does not search in the 15 years of tickets from trac

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Timo Rothenpieler via ffmpeg-devel]

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

On 9/15/2025 8:26 PM, Michael Niedermayer via ffmpeg-devel wrote:
> Hi Timo
> 
> On Mon, Sep 15, 2025 at 07:19:17PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
>> On 9/15/2025 2:57 PM, Michael Niedermayer via ffmpeg-devel wrote:
>>> Hi
>>>
>>> On Mon, Sep 15, 2025 at 02:06:07PM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
>>>> On 15/09/2025 13:09, Michael Niedermayer via ffmpeg-devel wrote:
>>> [...]
>>>>> Ideas, Comments ?
>>>>
>>>> I do think trac is a dead end software, and we want to eventually retire it.
>>>
>>> btw, anyone knows why the trac project seems dieing / dead ?
>>> Its a quite capable issue tracker ...
>>>
>>> also how is it related to redmine, which seems to have some support
>>> for importing trac ?
>>>
>>> Have we considered redmine as alternative ?
>>> If we could do a full import of trac, this may be a smoother
>>
>> redmine is apparently a "trac clone written in ruby".
>> No idea if it's database-compatible, or just similar idea but full
>> re-implementation.
>>
> 
>> But really, I don't see how in the long run a separate issue tracker from
>> Forgejo makes sense.
>> The issue IDs will eventually clash, and integration and linking between
>> them will be a right mess.
> 
> the mix of trac and Forgejo is already a mess if theres no _clean_
> way to import the tickets
> We would always have 15 years of ticket history outside our issue tracker
> 
> if you really want to have pull requests and issues have distinct positive numbers
> well, make one even and the other odd above the value where they would clash
> so it would be
> 0..20k Trac
> 20k-25k Forgejo
> 25k+ even Forgejo
> 25k+ odd redmine

That is not something that can be done, and honestly seems a bit silly 
to me.

> 
>>
>> 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.

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.

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.

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4742 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Gyan Doshi via ffmpeg-devel]

On 2025-09-16 12:05 am, Timo Rothenpieler via ffmpeg-devel wrote:
> On 9/15/2025 8:26 PM, Michael Niedermayer via ffmpeg-devel wrote:
>> Hi Timo
>>
>> On Mon, Sep 15, 2025 at 07:19:17PM +0200, Timo Rothenpieler via 
>> ffmpeg-devel wrote:
>>> On 9/15/2025 2:57 PM, Michael Niedermayer via ffmpeg-devel wrote:
>>>> Hi
>>>>
>>>> On Mon, Sep 15, 2025 at 02:06:07PM +0200, Timo Rothenpieler via 
>>>> ffmpeg-devel wrote:
>>>>> On 15/09/2025 13:09, Michael Niedermayer via ffmpeg-devel wrote:
>>>> [...]
>>>>>> Ideas, Comments ?
>>>>>
>>>>> I do think trac is a dead end software, and we want to eventually 
>>>>> retire it.
>>>>
>>>> btw, anyone knows why the trac project seems dieing / dead ?
>>>> Its a quite capable issue tracker ...
>>>>
>>>> also how is it related to redmine, which seems to have some support
>>>> for importing trac ?
>>>>
>>>> Have we considered redmine as alternative ?
>>>> If we could do a full import of trac, this may be a smoother
>>>
>>> redmine is apparently a "trac clone written in ruby".
>>> No idea if it's database-compatible, or just similar idea but full
>>> re-implementation.
>>>
>>
>>> But really, I don't see how in the long run a separate issue tracker 
>>> from
>>> Forgejo makes sense.
>>> The issue IDs will eventually clash, and integration and linking 
>>> between
>>> them will be a right mess.
>>
>> the mix of trac and Forgejo is already a mess if theres no _clean_
>> way to import the tickets
>> We would always have 15 years of ticket history outside our issue 
>> tracker
>>
>> if you really want to have pull requests and issues have distinct 
>> positive numbers
>> well, make one even and the other odd above the value where they 
>> would clash
>> so it would be
>> 0..20k Trac
>> 20k-25k Forgejo
>> 25k+ even Forgejo
>> 25k+ odd redmine
>
> That is not something that can be done, and honestly seems a bit silly 
> to me.
>
>>
>>>
>>> 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.
>
> 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.
>
> 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's best to have a single issue tracker.
It's best for the issue tracker to be integrated with the code workflow.

What can happen is that if an existing open trac issue is taken up for 
active resolution, then a new issue at Forgejo can be opened, with a 
reference to the trac issue. A comment can be left at trac linking to 
this new Forge issue, so all further activity occurs at code.ffmpeg. 
This would avoid any wholesale migration or duplication.

Regards,
Gyan

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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi Gyan

On Tue, Sep 16, 2025 at 12:39:37AM +0530, Gyan Doshi via ffmpeg-devel wrote:

> It's best to have a single issue tracker.

+1


> It's best for the issue tracker to be integrated with the code workflow.

+1


> 
> What can happen is that if an existing open trac issue is taken up for
> active resolution, then a new issue at Forgejo can be opened, with a
> reference to the trac issue. A comment can be left at trac linking to this
> new Forge issue, so all further activity occurs at code.ffmpeg. This would
> avoid any wholesale migration or duplication.

It can _IF_ someone spends the extra time and work.
How many people want to do that ?
And how many will do it ?
And what do we gain by avoiding "wholesale migration" ?

thx

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Gyan Doshi via ffmpeg-devel]

On 2025-09-16 03:16 am, Michael Niedermayer via ffmpeg-devel wrote:
>> What can happen is that if an existing open trac issue is taken up for
>> active resolution, then a new issue at Forgejo can be opened, with a
>> reference to the trac issue. A comment can be left at trac linking to this
>> new Forge issue, so all further activity occurs at code.ffmpeg. This would
>> avoid any wholesale migration or duplication.
> It can _IF_ someone spends the extra time and work.
> How many people want to do that ?
> And how many will do it ?

There's hardly any extra work.
Open a single issue at forge where the title says, "trac 1234: 
regression in ..."
Add a link to the trac issue in the body.
Post a comment at the trac issue: "continued at 
https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/12345"

Only do this for issues where someone is actively handling the ticket.


> And what do we gain by avoiding "wholesale migration" ?

Added bloat of thousands of dormant issues marked as open, many of which 
are invalid after these many years.

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

[FFmpeg-devel] trac ticket statistics Was: Re: Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi Gyan

On Tue, Sep 16, 2025 at 10:09:14AM +0530, Gyan Doshi via ffmpeg-devel wrote:
> 
> 
> On 2025-09-16 03:16 am, Michael Niedermayer via ffmpeg-devel wrote:

[...]

> > And what do we gain by avoiding "wholesale migration" ?
> 
> Added bloat of thousands of dormant issues marked as open, many of which are
> invalid after these many years.

This is not an accurate description of the situation

If you look at trac, there are
 690    open tickets
 176    reopened tickets
2307    new tickets
5033    fixed tickets
1751    invalid tickets
 280    wont fix tickets
 565    duplicate tickets
 266    non reproduceable tickets
 593    tickets waiting for user input

What you can see here, is there are only 690 open tickets, that is not thousands

there are also 593 Tickets marked as needs_more_input,
these should not end on a read only system


We can also look at the last modified dates on tickets

last modified:
new (re)open
337    104      in 2024-09-23 to 2025-09-23
353     80      in 2023-09-23 to 2024-09-23
328     93      in 2022-09-23 to 2023-09-23
159     59      in 2021-09-23 to 2022-09-23
162     66      in 2020-09-23 to 2021-09-23
141     74      in 2019-09-23 to 2020-09-23
145     36      in 2018-09-23 to 2019-09-23
132     35      in 2017-09-23 to 2018-09-23
139     61      in 2016-09-23 to 2017-09-23
130     75      in 2015-09-23 to 2016-09-23

we have ATM 2307 new tickets, 1018 of these are
from the last 3 years.

I dont think droping all this, achieves anything positive.
You will have the same number of new tickets within 2-3 years, and
loss of past analysis/work on these issues.

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi Gyan

On Tue, Sep 16, 2025 at 10:09:14AM +0530, Gyan Doshi via ffmpeg-devel wrote:
> 
> 
> On 2025-09-16 03:16 am, Michael Niedermayer via ffmpeg-devel wrote:
> > > What can happen is that if an existing open trac issue is taken up for
> > > active resolution, then a new issue at Forgejo can be opened, with a
> > > reference to the trac issue. A comment can be left at trac linking to this
> > > new Forge issue, so all further activity occurs at code.ffmpeg. This would
> > > avoid any wholesale migration or duplication.
> > It can _IF_ someone spends the extra time and work.
> > How many people want to do that ?
> > And how many will do it ?
> 
> There's hardly any extra work.
> Open a single issue at forge where the title says, "trac 1234: regression in
> ..."
> Add a link to the trac issue in the body.
> Post a comment at the trac issue: "continued at
> https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/12345"

Can you show me 10 cases where this has been done ?
Or even just one ?
Or even just tell me how one could reliably search for issues that continue a trac ticket ?

thx

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

Those who are best at talking, realize last or never when they are wrong.

[-- 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

[FFmpeg-devel] Re: trac ticket statistics Was: Re: Re: [RFC] Issue tracker

[Gyan Doshi via ffmpeg-devel]

On 2025-09-24 03:20 am, Michael Niedermayer via ffmpeg-devel wrote:
> Hi Gyan
>
> On Tue, Sep 16, 2025 at 10:09:14AM +0530, Gyan Doshi via ffmpeg-devel wrote:
>>
>> On 2025-09-16 03:16 am, Michael Niedermayer via ffmpeg-devel wrote:
> [...]
>
>>> And what do we gain by avoiding "wholesale migration" ?
>> Added bloat of thousands of dormant issues marked as open, many of which are
>> invalid after these many years.
> This is not an accurate description of the situation
>
> If you look at trac, there are
>   690    open tickets
>   176    reopened tickets
> 2307    new tickets
> 5033    fixed tickets
> 1751    invalid tickets
>   280    wont fix tickets
>   565    duplicate tickets
>   266    non reproduceable tickets
>   593    tickets waiting for user input
>
> What you can see here, is there are only 690 open tickets, that is not thousands

The oldest 'new' ticket is from 2013, so that label is misleading. By 
open, I meant unresolved tickets so that includes open + reopened + new 
+ waiting for user input = 690 + 176 + 2307 + 593 = 3766 tickets.
> there are also 593 Tickets marked as needs_more_input,
> these should not end on a read only system

It should be possible to revive them but on a case-by-case basis. The 
oldest 'needs_more_info' ticket #228 has its last activity in Dec 2013. 
There's no point in blindly migrating such tickets wholesale. Maybe it's 
possible to add a banner on trac so that when someone lands on a ticket, 
the banner tells them where they can open a new issue (on F) to report a 
brand-new issue or continue a trac ticket. A few of us can have 
permissions to update trac so that we can add a link to F if a ticket is 
revived. trac can then become read-only for the rest.

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

[FFmpeg-devel] Re: trac ticket statistics Was: Re: Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi Gyan

On Wed, Sep 24, 2025 at 04:26:53PM +0530, Gyan Doshi via ffmpeg-devel wrote:
> 
> 
> On 2025-09-24 03:20 am, Michael Niedermayer via ffmpeg-devel wrote:
> > Hi Gyan
> > 
> > On Tue, Sep 16, 2025 at 10:09:14AM +0530, Gyan Doshi via ffmpeg-devel wrote:
> > > 
> > > On 2025-09-16 03:16 am, Michael Niedermayer via ffmpeg-devel wrote:
> > [...]
> > 
> > > > And what do we gain by avoiding "wholesale migration" ?
> > > Added bloat of thousands of dormant issues marked as open, many of which are
> > > invalid after these many years.
> > This is not an accurate description of the situation
> > 
> > If you look at trac, there are
> >   690    open tickets
> >   176    reopened tickets
> > 2307    new tickets
> > 5033    fixed tickets
> > 1751    invalid tickets
> >   280    wont fix tickets
> >   565    duplicate tickets
> >   266    non reproduceable tickets
> >   593    tickets waiting for user input
> > 
> > What you can see here, is there are only 690 open tickets, that is not thousands
> 
> The oldest 'new' ticket is from 2013, so that label is misleading.

They are "new" in the sense that they have not been categorized between
valid+open and invalid+closed

We can categorize them, we can also automatically change their status/resolution
But they should be migrated to the new tracker if we choose a new tracker IMO


> By open,
> I meant unresolved tickets so that includes open + reopened + new + waiting
> for user input = 690 + 176 + 2307 + 593 = 3766 tickets.

> > there are also 593 Tickets marked as needs_more_input,
> > these should not end on a read only system
> 
> It should be possible to revive them but on a case-by-case basis.

That is only possible, if we have a volunteer to do that. Iam not sure
who that would be.


> The oldest
> 'needs_more_info' ticket #228 has its last activity in Dec 2013. There's no
> point in blindly migrating such tickets wholesale.

#228 closed
are there other tickets which have incorrect status or resoluton ?

if so, we should fix that.
There is value in going over these old tickets. And cleaning it up


> Maybe it's possible to
> add a banner on trac so that when someone lands on a ticket, the banner
> tells them where they can open a new issue (on F) to report a brand-new
> issue or continue a trac ticket. A few of us can have permissions to update
> trac so that we can add a link to F if a ticket is revived. trac can then
> become read-only for the rest.

Again, we have no volunteer to do any of this.
If we do then she can already now go over new tickets and change them to
open or closed. Similar for other tickets that have the wrong status/resolution


thx

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato

[-- 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

[FFmpeg-devel] Re: trac ticket statistics Was: Re: Re: [RFC] Issue tracker

[Gyan Doshi via ffmpeg-devel]

On 2025-09-28 06:14 am, Michael Niedermayer via ffmpeg-devel wrote:
>>> What you can see here, is there are only 690 open tickets, that is not thousands
>> The oldest 'new' ticket is from 2013, so that label is misleading.
> They are "new" in the sense that they have not been categorized between
> valid+open and invalid+closed
>
>> It should be possible to revive them but on a case-by-case basis.
> That is only possible, if we have a volunteer to do that. Iam not sure
> who that would be.

If there is a volunteer, they can categorize tickets on trac and then we 
migrate the open & valid tickets and avoid bloat.
If there is no volunteer, then after migration, they will still remain 
dormant on the new tracker and become bloat.

As long as human attention is the bottleneck, I don't see the value in 
adding jetsam to the new tracker.

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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Rémi Denis-Courmont via ffmpeg-devel]

Le maanantaina 15. syyskuuta 2025, 0.23.17 Itä-Euroopan kesäaika Michael 
Niedermayer via ffmpeg-devel a écrit :
> Hi everyone
> 
> trac supports, custom search queries, customly formated results
> 
> People can vote on tickets,

I don't see much value in voting on tickets. It would be useful to know how 
many people are able and not able to reproduce a problem, but that's not how 
votes are used.

With that said, you can assign thumbs-up, thumbs-down and other emojis in 
Forgejo, if you want to vote on something.

> we can have custom ticket states and custom
> workflow on tickets.

We can have custom labels for tickets and MRs.

However before FFmpeg can consider migrating from Trac to Forgejo, we have to 
consider the (anti)spam implications. I suppose there is not much spam yet 
because Gitlab is vastly more popular, but that's probably only a matter of 
time.

If code.ffmpeg.org needs to be locked down with manual approval like 
FreeDesktop and VideoLAN's Gitlab instances, then migrating the bug reporting 
there may not be such a great idea. Unless we specifically want to restrict bug 
reporting to trusted community members.

Otherwise, I don't really see any benefit to Trac. Forgejo would allow us to 
link issues and MRs, and presumably also automatically close issues. We just 
need to agree whether to migrate existing issues or not (and if we do, find 
someone to do the SQL wizardry).

-- 
德尼-库尔蒙‧雷米
Tapio's place new town, former Finnish Republic of Uusimaa



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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

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

Hi Remi

On Sun, Sep 28, 2025 at 10:54:14AM +0300, Rémi Denis-Courmont via ffmpeg-devel wrote:
> Le maanantaina 15. syyskuuta 2025, 0.23.17 Itä-Euroopan kesäaika Michael 
> Niedermayer via ffmpeg-devel a écrit :
[...]

> With that said, you can assign thumbs-up, thumbs-down and other emojis in 
> Forgejo, if you want to vote on something.

The problem is, these are not displayed in search and cannot be sorted on.

So while in trac one can simply sort for tickets with most votes, in Forgejo
one cannot search for tickets with most of "some emoji"

So we can vote in a ticket but not accross tickets.

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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1.1: Type: text/plain, Size: 1644 bytes --]

Hi Remi

On Sun, Sep 28, 2025 at 10:54:14AM +0300, Rémi Denis-Courmont via ffmpeg-devel wrote:
> Le maanantaina 15. syyskuuta 2025, 0.23.17 Itä-Euroopan kesäaika Michael 
> Niedermayer via ffmpeg-devel a écrit :

[...]

> > we can have custom ticket states and custom
> > workflow on tickets.
> 
> We can have custom labels for tickets and MRs.
> 
> However before FFmpeg can consider migrating from Trac to Forgejo, we have to 
> consider the (anti)spam implications. I suppose there is not much spam yet 
> because Gitlab is vastly more popular, but that's probably only a matter of 
> time.
> 
> If code.ffmpeg.org needs to be locked down with manual approval like 
> FreeDesktop and VideoLAN's Gitlab instances, then migrating the bug reporting 
> there may not be such a great idea. Unless we specifically want to restrict bug 
> reporting to trusted community members.

I agree, anti-spam is a big deal. trac has quite extensive anti spam capabilities.


> 
> Otherwise, I don't really see any benefit to Trac. Forgejo would allow us to 
> link issues and MRs, and presumably also automatically close issues. We just 
> need to agree whether to migrate existing issues or not (and if we do, find 
> someone to do the SQL wizardry).

AI generated migration script attacht.
This is untested and is very unlikely to work as is, but parts of it could
be usefull i guess or it could serve as a starting point.

thx


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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell

[-- Attachment #1.1.2: trac_to_forgejo_migrator.py --]
[-- Type: text/x-python, Size: 24662 bytes --]

#!/usr/bin/env python3
"""
Trac → Forgejo issue migrator (tickets, comments, labels, milestones, attachments-as-links)

✅ Features
- Migrates Trac tickets (title, body, metadata) to Forgejo issues
- Preserves reporter/owner via user mapping
- Converts common Trac wiki markup → Markdown (lightweight, optional)
- Replays comments with original author & timestamp banners
- Recreates labels (component, type, priority, status/resolution) if missing
- Recreates milestones (by name) if missing and assigns to issues
- Closes issues that were closed in Trac and adds a resolution label
- Adds links for attachments (keeps them downloadable from your Trac site)
- Idempotent: keeps a trac_id ↔ forgejo_issue index mapping file
- Dry‑run mode

⚙️ Requirements
- Python 3.8+
- pip install requests pyyaml

🧰 Usage
1) Create a config YAML (example below) as config.yaml
2) Run:  
   python3 trac_to_forgejo_migrator.py --config config.yaml --dry-run   # preview  
   python3 trac_to_forgejo_migrator.py --config config.yaml              # migrate

Example config.yaml
-------------------
forgejo:
  base_url: "https://forgejo.example.org"   # no trailing slash
  owner: "your-org"
  repo: "your-repo"
  token: "<personal-access-token>"          # needs repo:write, admin:repo_hook for labels/milestones
  rate_limit_sleep_sec: 0.2                  # politeness pause between API calls

trac:
  # SQLite DB path of your Trac instance (read-only). For MySQL/PostgreSQL, see notes below.
  sqlite_path: "/var/lib/trac/project/db/trac.db"
  # Base URL of your Trac site (used to link back to original ticket & attachments)
  base_url: "https://trac.example.org"

migrate:
  # restrict to a subset (omit or set to [] for all)
  include_ticket_ids: []
  exclude_ticket_ids: []
  # when True, prefix titles with "[Trac #ID]" for easy cross-reference
  prefix_trac_id_in_title: true
  # If a Forgejo issue already exists for a Trac id (mapping file), it will be skipped
  dry_run: false

mapping_files:
  # JSON file created/updated by this script to remember Trac→Forgejo mapping
  id_map_path: "./trac_forgejo_id_map.json"

users:
  # Map Trac usernames → Forgejo usernames (for assignees); reporter shown in body regardless
  # Unmapped users are left as plain text.
  "michael": "michael-niedermayer"
  "alice": "alice"

labels:
  # Optional color overrides (6-hex without #). Missing labels get a stable hash color.
  colors:
    "component/avcodec": "0366d6"
    "resolution/fixed": "2ea043"

markdown:
  # If you have pandoc installed and want better conversion, set to path like "/usr/bin/pandoc"
  pandoc_path: null
  # Or use the built-in lightweight converter (recommended default)
  use_lightweight_converter: true

notes:
  # For MySQL/PostgreSQL backends, you can export SQLite first (or extend the code to use PyMySQL/psycopg2)
  # Attachments: this script links to Trac's attachment URLs; to *upload* into Forgejo later, see TODOs in code.

"""
from __future__ import annotations
import argparse
import dataclasses
import datetime as dt
import hashlib
import json
import os
import re
import sqlite3
import subprocess
import sys
import time
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

try:
    import yaml  # type: ignore
except Exception:  # pragma: no cover
    print("ERROR: pyyaml is required. pip install pyyaml", file=sys.stderr)
    sys.exit(2)

ISO = "%Y-%m-%d %H:%M:%S%z"

# ---------------------------- Utilities ----------------------------

def ts_from_trac(microseconds_since_epoch: int) -> dt.datetime:
    """Trac stores timestamps as microseconds since epoch."""
    # Trac uses microseconds epoch (int). Interpret as UTC.
    sec = microseconds_since_epoch / 1_000_000.0
    return dt.datetime.fromtimestamp(sec, tz=dt.timezone.utc)


def banner(author: str, when: dt.datetime) -> str:
    return f"_Originally posted by **{author or 'unknown'}** on {when.strftime('%Y-%m-%d %H:%M:%S %Z')}_\n\n"


def stable_color(name: str) -> str:
    """Derive a 6-hex color from a name (no leading '#')."""
    h = hashlib.sha1(name.encode("utf-8")).hexdigest()
    return h[:6]


# ----------------------- Lightweight Trac→MD -----------------------
TRIPLE_SINGLE = re.compile(r"'''(.*?)'''", re.DOTALL)
DOUBLE_SINGLE = re.compile(r"''(.*?)''", re.DOTALL)
HEADING = re.compile(r"^(=+)[ \t]*(.*?)[ \t]*=+$", re.MULTILINE)
WIKI_LINK = re.compile(r"\[(?:wiki:)?([^\] ]+)(?:\s+([^\]]+))?\]")
HTTP_LINK = re.compile(r"\[(https?://[^\] ]+)(?:\s+([^\]]+))?\]")
BR = re.compile(r"\[\[BR\]\]")


def trac_to_markdown(text: str) -> str:
    """Very small subset of Trac wiki → Markdown conversions.
    Keeps unknown markup as-is to avoid data loss.
    """
    if not text:
        return ""
    out = text
    # line breaks
    out = BR.sub("  \n", out)
    # bold/italic
    out = TRIPLE_SINGLE.sub(r"**\1**", out)
    out = DOUBLE_SINGLE.sub(r"*\1*", out)
    # headings: '== Title ==' → '## Title'
    def _h(m: re.Match) -> str:
        level = len(m.group(1))
        level = min(max(level, 1), 6)
        return f"{'#' * level} {m.group(2).strip()}"
    out = HEADING.sub(_h, out)
    # external links [http://url label]
    out = HTTP_LINK.sub(lambda m: f"[{m.group(2) or m.group(1)}]({m.group(1)})", out)
    # wiki-ish links [wiki:Page Label] or [Page Label] → [Label](Page)
    def _wiki(m: re.Match) -> str:
        target = m.group(1)
        label = m.group(2) or target
        # naive: leave as code-ish if it looks like CamelCase wiki page
        return f"[{label}]({target})"
    out = WIKI_LINK.sub(_wiki, out)
    return out


def maybe_pandoc(text: str, pandoc_path: Optional[str]) -> str:
    if not text:
        return ""
    if not pandoc_path:
        return text
    try:
        p = subprocess.run(
            [pandoc_path, "-f", "trac", "-t", "gfm"],
            input=text.encode("utf-8"),
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            check=True,
        )
        return p.stdout.decode("utf-8")
    except Exception as e:
        # fall back silently
        return text


# ----------------------------- Trac DB -----------------------------
@dataclasses.dataclass
class TracTicket:
    id: int
    type: str
    time: dt.datetime
    changetime: dt.datetime
    component: Optional[str]
    severity: Optional[str]
    priority: Optional[str]
    owner: Optional[str]
    reporter: Optional[str]
    cc: Optional[str]
    version: Optional[str]
    milestone: Optional[str]
    status: str
    resolution: Optional[str]
    summary: str
    description: str


@dataclasses.dataclass
class TracChange:
    ticket: int
    time: dt.datetime
    author: Optional[str]
    field: str
    oldvalue: Optional[str]
    newvalue: Optional[str]


@dataclasses.dataclass
class TracAttachment:
    ticket: int
    filename: str
    author: Optional[str]
    time: dt.datetime
    description: Optional[str]
    size: Optional[int]


class Trac:
    def __init__(self, sqlite_path: str):
        self.sqlite_path = sqlite_path
        self.conn = sqlite3.connect(sqlite_path)
        self.conn.row_factory = sqlite3.Row

    def fetch_ticket_ids(self) -> List[int]:
        cur = self.conn.execute("SELECT id FROM ticket ORDER BY id ASC")
        return [row[0] for row in cur.fetchall()]

    def fetch_ticket(self, tid: int) -> TracTicket:
        row = self.conn.execute(
            "SELECT id, type, time, changetime, component, severity, priority, owner, reporter, cc, version, milestone, status, resolution, summary, description FROM ticket WHERE id=?",
            (tid,),
        ).fetchone()
        if not row:
            raise KeyError(f"Ticket {tid} not found")
        return TracTicket(
            id=row["id"],
            type=row["type"] or "",
            time=ts_from_trac(row["time"]),
            changetime=ts_from_trac(row["changetime"]),
            component=row["component"],
            severity=row["severity"],
            priority=row["priority"],
            owner=row["owner"],
            reporter=row["reporter"],
            cc=row["cc"],
            version=row["version"],
            milestone=row["milestone"],
            status=row["status"] or "new",
            resolution=row["resolution"],
            summary=row["summary"] or "",
            description=row["description"] or "",
        )

    def fetch_changes(self, tid: int) -> List[TracChange]:
        cur = self.conn.execute(
            "SELECT ticket, time, author, field, oldvalue, newvalue FROM ticket_change WHERE ticket=? ORDER BY time ASC, rowid ASC",
            (tid,),
        )
        out: List[TracChange] = []
        for r in cur.fetchall():
            out.append(
                TracChange(
                    ticket=r["ticket"],
                    time=ts_from_trac(r["time"]),
                    author=r["author"],
                    field=r["field"],
                    oldvalue=r["oldvalue"],
                    newvalue=r["newvalue"],
                )
            )
        return out

    def fetch_attachments(self, tid: int) -> List[TracAttachment]:
        # Trac 'attachment' table schema: type, id, filename, size, time, description, author, ipnr
        cur = self.conn.execute(
            "SELECT filename, size, time, description, author FROM attachment WHERE type='ticket' AND id=? ORDER BY time ASC",
            (str(tid),),
        )
        out: List[TracAttachment] = []
        for r in cur.fetchall():
            out.append(
                TracAttachment(
                    ticket=tid,
                    filename=r["filename"],
                    author=r["author"],
                    time=ts_from_trac(r["time"]),
                    description=r["description"],
                    size=r["size"],
                )
            )
        return out


# --------------------------- Forgejo Client ---------------------------
class Forgejo:
    def __init__(self, base_url: str, owner: str, repo: str, token: str, rate_sleep: float = 0.0):
        self.base = base_url.rstrip('/')
        self.owner = owner
        self.repo = repo
        self.session = requests.Session()
        self.session.headers.update({
            'Authorization': f'token {token}',
            'Accept': 'application/json',
        })
        self.rate_sleep = rate_sleep

    # ---- helpers ----
    def _url(self, path: str) -> str:
        return f"{self.base}/api/v1/repos/{self.owner}/{self.repo}{path}"

    def _req(self, method: str, url: str, **kw) -> requests.Response:
        r = self.session.request(method, url, timeout=60, **kw)
        if self.rate_sleep:
            time.sleep(self.rate_sleep)
        if r.status_code >= 400:
            raise RuntimeError(f"HTTP {r.status_code} for {url}: {r.text[:400]}")
        return r

    # ---- labels ----
    def list_labels(self) -> Dict[str, Dict[str, Any]]:
        url = self._url("/labels")
        r = self._req('GET', url)
        items = r.json()
        return {it['name']: it for it in items}

    def ensure_label(self, name: str, color: Optional[str] = None, description: str = "") -> int:
        existing = self.list_labels()
        if name in existing:
            return existing[name]['id']
        url = self._url("/labels")
        payload = {
            'name': name,
            'color': f"#{(color or stable_color(name)).lstrip('#')}",
            'description': description,
        }
        r = self._req('POST', url, json=payload)
        return r.json()['id']

    # ---- milestones ----
    def list_milestones(self) -> Dict[str, Dict[str, Any]]:
        url = self._url("/milestones")
        r = self._req('GET', url)
        items = r.json()
        return {it['title']: it for it in items}

    def ensure_milestone(self, title: str) -> Optional[int]:
        if not title:
            return None
        existing = self.list_milestones()
        if title in existing:
            return existing[title]['id']
        url = self._url("/milestones")
        r = self._req('POST', url, json={'title': title})
        return r.json()['id']

    # ---- issues ----
    def create_issue(self, title: str, body: str, labels: List[str], assignees: List[str], milestone_id: Optional[int]) -> Dict[str, Any]:
        # Ensure labels exist and collect ids
        label_ids: List[int] = []
        for ln in labels:
            if not ln:
                continue
            lid = self.ensure_label(ln)
            label_ids.append(lid)
        payload: Dict[str, Any] = {
            'title': title,
            'body': body,
            'assignees': assignees or [],
            'labels': label_ids,
        }
        if milestone_id:
            payload['milestone'] = milestone_id
        url = self._url('/issues')
        r = self._req('POST', url, json=payload)
        return r.json()

    def close_issue(self, index: int) -> None:
        url = self._url(f'/issues/{index}')
        self._req('PATCH', url, json={'state': 'closed'})

    def comment(self, index: int, body: str) -> Dict[str, Any]:
        url = self._url(f'/issues/{index}/comments')
        r = self._req('POST', url, json={'body': body})
        return r.json()


# ----------------------------- Migration -----------------------------
@dataclasses.dataclass
class Config:
    forgejo_base: str
    forgejo_owner: str
    forgejo_repo: str
    forgejo_token: str
    rate_sleep: float

    trac_sqlite: str
    trac_base_url: str

    include_ids: List[int]
    exclude_ids: List[int]
    prefix_trac_id_in_title: bool

    id_map_path: str

    user_map: Dict[str, str]
    label_colors: Dict[str, str]

    pandoc_path: Optional[str]
    use_light_conv: bool

    dry_run: bool

    @staticmethod
    def from_yaml(d: Dict[str, Any]) -> 'Config':
        forgejo = d.get('forgejo', {})
        trac = d.get('trac', {})
        migrate = d.get('migrate', {})
        mapping_files = d.get('mapping_files', {})
        users = d.get('users', {})
        labels = d.get('labels', {})
        markdown = d.get('markdown', {})
        return Config(
            forgejo_base=forgejo['base_url'],
            forgejo_owner=forgejo['owner'],
            forgejo_repo=forgejo['repo'],
            forgejo_token=forgejo['token'],
            rate_sleep=float(forgejo.get('rate_limit_sleep_sec', 0) or 0),
            trac_sqlite=trac['sqlite_path'],
            trac_base_url=trac['base_url'].rstrip('/'),
            include_ids=list(migrate.get('include_ticket_ids') or []),
            exclude_ids=list(migrate.get('exclude_ticket_ids') or []),
            prefix_trac_id_in_title=bool(migrate.get('prefix_trac_id_in_title', True)),
            id_map_path=mapping_files.get('id_map_path', './trac_forgejo_id_map.json'),
            user_map={str(k): str(v) for k, v in (users or {}).items()},
            label_colors=labels.get('colors', {}),
            pandoc_path=markdown.get('pandoc_path'),
            use_light_conv=bool(markdown.get('use_lightweight_converter', True)),
            dry_run=bool(migrate.get('dry_run', False)),
        )


class Migrator:
    def __init__(self, cfg: Config):
        self.cfg = cfg
        self.trac = Trac(cfg.trac_sqlite)
        self.forge = Forgejo(cfg.forgejo_base, cfg.forgejo_owner, cfg.forgejo_repo, cfg.forgejo_token, rate_sleep=cfg.rate_sleep)
        self.id_map = self._load_id_map(cfg.id_map_path)

    # ---------- mapping persistence ----------
    def _load_id_map(self, path: str) -> Dict[str, Any]:
        if os.path.exists(path):
            with open(path, 'r', encoding='utf-8') as f:
                return json.load(f)
        return {}

    def _save_id_map(self) -> None:
        tmp = self.cfg.id_map_path + ".tmp"
        with open(tmp, 'w', encoding='utf-8') as f:
            json.dump(self.id_map, f, indent=2, ensure_ascii=False)
        os.replace(tmp, self.cfg.id_map_path)

    def _map_set(self, trac_id: int, issue_index: int) -> None:
        self.id_map[str(trac_id)] = {'issue_index': issue_index}
        self._save_id_map()

    def _map_get(self, trac_id: int) -> Optional[int]:
        entry = self.id_map.get(str(trac_id))
        if entry:
            return int(entry['issue_index'])
        return None

    # ---------- conversion helpers ----------
    def _convert_body(self, t: TracTicket) -> str:
        header = [
            f"**Trac ticket #{t.id}**",
            f"Reporter: `{t.reporter or ''}`",
            f"Owner: `{t.owner or ''}`",
            f"Created: {t.time.strftime('%Y-%m-%d %H:%M:%S %Z')}",
            f"Last change: {t.changetime.strftime('%Y-%m-%d %H:%M:%S %Z')}",
            f"Status: {t.status}"
            + (f" ({t.resolution})" if t.resolution else ""),
            f"Original: {self.cfg.trac_base_url}/ticket/{t.id}",
            "",
            "---",
            "",
        ]
        body_raw = t.description or ""
        if self.cfg.pandoc_path:
            body_md = maybe_pandoc(body_raw, self.cfg.pandoc_path)
        elif self.cfg.use_light_conv:
            body_md = trac_to_markdown(body_raw)
        else:
            body_md = body_raw
        return "\n".join(header) + body_md

    def _labels_for(self, t: TracTicket) -> List[str]:
        labs: List[str] = []
        if t.component:
            labs.append(f"component/{t.component}")
        if t.type:
            labs.append(f"type/{t.type}")
        if t.priority:
            labs.append(f"priority/{t.priority}")
        if t.severity:
            labs.append(f"severity/{t.severity}")
        if t.version:
            labs.append(f"version/{t.version}")
        for kw in (t.keywords or '').replace(',', ' ').split():
            labs.append(f"keyword/{kw}")
        # status/resolution as labels (state handled separately)
        labs.append(f"status/{t.status}")
        if t.resolution:
            labs.append(f"resolution/{t.resolution}")
        return labs

    def _ensure_labels(self, labels: Iterable[str]) -> None:
        for ln in labels:
            if not ln:
                continue
            color = self.cfg.label_colors.get(ln)
            desc = "Imported from Trac"
            if self.cfg.dry_run:
                print(f"DRY-RUN: ensure label {ln} ({color or stable_color(ln)})")
            else:
                self.forge.ensure_label(ln, color=color, description=desc)

    def _ensure_milestone(self, t: TracTicket) -> Optional[int]:
        if not t.milestone:
            return None
        if self.cfg.dry_run:
            print(f"DRY-RUN: ensure milestone {t.milestone}")
            return None
        return self.forge.ensure_milestone(t.milestone)

    def _assignees(self, t: TracTicket) -> List[str]:
        owner = (t.owner or '').strip()
        if not owner:
            return []
        mapped = self.cfg.user_map.get(owner)
        return [mapped] if mapped else []

    # ---------- comments & attachments ----------
    def _emit_comments(self, idx: int, t: TracTicket, changes: List[TracChange]) -> None:
        # Only 'comment' field entries produce issue comments; other changes are summarized.
        # We'll also emit non-empty status/owner changes to preserve history.
        for ch in changes:
            if ch.field == 'comment' and (ch.newvalue or '').strip():
                text = ch.newvalue or ''
                if self.cfg.pandoc_path:
                    text_md = maybe_pandoc(text, self.cfg.pandoc_path)
                elif self.cfg.use_light_conv:
                    text_md = trac_to_markdown(text)
                else:
                    text_md = text
                body = banner(ch.author or 'unknown', ch.time) + text_md
                if self.cfg.dry_run:
                    print(f"DRY-RUN: add comment to #{idx}: {body[:80]!r}...")
                else:
                    self.forge.comment(idx, body)
            elif ch.field in {"status", "owner", "milestone", "priority", "component", "resolution"}:
                # summarize as small audit trail comment
                oldv = ch.oldvalue or ""
                newv = ch.newvalue or ""
                if oldv == newv:
                    continue
                body = banner(ch.author or 'unknown', ch.time) + f"**Change**: `{ch.field}` → `{newv}` (was `{oldv}`)"
                if self.cfg.dry_run:
                    print(f"DRY-RUN: add audit comment to #{idx}: {body[:80]!r}...")
                else:
                    self.forge.comment(idx, body)

    def _emit_attachments(self, idx: int, t: TracTicket, atts: List[TracAttachment]) -> None:
        if not atts:
            return
        for a in atts:
            url = f"{self.cfg.trac_base_url}/attachment/ticket/{t.id}/{a.filename}"
            meta = f"Attachment: **{a.filename}** ({a.size or '?'} bytes) — {url}"
            body = banner(a.author or 'unknown', a.time) + meta
            if self.cfg.dry_run:
                print(f"DRY-RUN: add attachment note to #{idx}: {body}")
            else:
                self.forge.comment(idx, body)

    # ---------- main unit of work ----------
    def migrate_one(self, tid: int) -> None:
        if self.cfg.exclude_ids and tid in self.cfg.exclude_ids:
            print(f"Skip ticket {tid} (excluded)")
            return
        mapped = self._map_get(tid)
        if mapped:
            print(f"Ticket {tid} already migrated as issue #{mapped}")
            return
        t = self.trac.fetch_ticket(tid)
        labels = self._labels_for(t)
        self._ensure_labels(labels)
        ms_id = self._ensure_milestone(t)

        title = t.summary
        if self.cfg.prefix_trac_id_in_title:
            title = f"[Trac #{t.id}] {title}"

        body = self._convert_body(t)
        assignees = self._assignees(t)

        if self.cfg.dry_run:
            print(f"DRY-RUN: would create issue for Trac {tid}: title={title!r}, labels={labels}, assignees={assignees}, milestone={ms_id}")
            idx = -1
        else:
            issue = self.forge.create_issue(title, body, labels, assignees, ms_id)
            idx = int(issue['number']) if 'number' in issue else int(issue['index'])
            self._map_set(tid, idx)
            print(f"Created Forgejo issue #{idx} for Trac {tid}")

        # comments & attachments
        changes = self.trac.fetch_changes(tid)
        atts = self.trac.fetch_attachments(tid)
        if self.cfg.dry_run:
            print(f"DRY-RUN: would add {sum(1 for c in changes if c.field=='comment' and (c.newvalue or '').strip())} comments and {len(atts)} attachments to issue #{idx}")
        else:
            self._emit_comments(idx, t, changes)
            self._emit_attachments(idx, t, atts)

        # close if needed
        if t.status.lower() == 'closed':
            if self.cfg.dry_run:
                print(f"DRY-RUN: would close issue #{idx}")
            else:
                self.forge.close_issue(idx)
                print(f"Closed issue #{idx} (resolution={t.resolution})")

    def run(self) -> None:
        if self.cfg.include_ids:
            ids = self.cfg.include_ids
        else:
            ids = self.trac.fetch_ticket_ids()
        for tid in ids:
            try:
                self.migrate_one(tid)
            except Exception as e:
                print(f"ERROR migrating ticket {tid}: {e}", file=sys.stderr)


# ----------------------------- CLI entry -----------------------------

def load_config(path: str) -> Config:
    with open(path, 'r', encoding='utf-8') as f:
        d = yaml.safe_load(f)
    return Config.from_yaml(d)


def main() -> None:
    ap = argparse.ArgumentParser(description="Migrate Trac tickets to Forgejo issues")
    ap.add_argument('--config', required=True, help='Path to YAML config')
    ap.add_argument('--dry-run', action='store_true', help='Force dry-run (overrides config)')
    args = ap.parse_args()

    cfg = load_config(args.config)
    if args.dry_run:
        cfg.dry_run = True

    mig = Migrator(cfg)
    mig.run()


if __name__ == '__main__':
    main()

[-- 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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Jacob Lifshay via ffmpeg-devel]

On September 28, 2025 2:18:40 AM PDT, Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> On Sun, Sep 28, 2025 at 10:54:14AM +0300, Rémi Denis-Courmont via ffmpeg-devel wrote:
> > Otherwise, I don't really see any benefit to Trac. Forgejo would allow us to 
> > link issues and MRs, and presumably also automatically close issues. We just 
> > need to agree whether to migrate existing issues or not (and if we do, find 
> > someone to do the SQL wizardry).
> 
> AI generated migration script attacht.
> This is untested and is very unlikely to work as is, but parts of it could
> be usefull i guess or it could serve as a starting point.

something that's much more likely than AI to work is trac2gitea, I found some people working on their trac to forgejo migration that were talking about using that, maybe collaborate and/or copy them?
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4161

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

[FFmpeg-devel] Re: [RFC] Issue tracker

[Rémi Denis-Courmont via ffmpeg-devel]

Le sunnuntai 28. syyskuuta 2025, 11.51.13 Itä-Euroopan kesäaika Michael 
Niedermayer via ffmpeg-devel a écrit :
> Hi Remi
> 
> On Sun, Sep 28, 2025 at 10:54:14AM +0300, Rémi Denis-Courmont via ffmpeg-
devel wrote:
> > Le maanantaina 15. syyskuuta 2025, 0.23.17 Itä-Euroopan kesäaika Michael
> 
> > Niedermayer via ffmpeg-devel a écrit :
> [...]
> 
> > With that said, you can assign thumbs-up, thumbs-down and other emojis in
> > Forgejo, if you want to vote on something.
> 
> The problem is, these are not displayed in search and cannot be sorted on.

I fail to see a "problem". Most if not all developers won't fix bugs based on 
popularity votes. And even if you or one other developer does look for votes, 
over time the most voted issues would be difficult or questionable feature 
requests that are left at the top of the list indefinitely.

Not very helpful.

> So we can vote in a ticket but not accross tickets.

IMO, that's actually much more relevant - it tells us if many people have 
opinions one way or the other on the bug / comment / MR.

It's not like anyone except maybe you and a few other devs scour through all 
bug reports to vote on them, so relative bug scores are pretty meaningless.

-- 
ヅニ-クーモン・レミ
Villeneuve de Tapiola, ex-République finlandaise d´Uusimaa



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