[FFmpeg-devel] Regarding Git Tooling

[FFmpeg-devel] Regarding Git Tooling

[Marth64]

Hello, in the context of a GA member,

I think there is general interest in modernizing technical tooling
specifically regarding ML/patch workflow vs. integrated git solution.
Both have their merits. I think what we have today is optimized for
some but cumbersome for many. Like shopping for a drill, it is good to
step back from time to time and ensure we have the right tools.

I think the problem statement of productivity being impacted from
outgrowing the current tooling is different from who is hosting it.

These are some options I noticed interest in (in no particular order):
- Forgejo
- GitLab
- Mailing List/Patch Workflow (current solution)

If we evaluate this as choosing a software appliance and put aside
"who is the host" I think we can have a good discussion. There could
be value in coming to consensus on one step, then moving on to the
next.

The goal is not to spin around on which tool is better but I am wondering,
- What other options would the community consider and any relevant pros/cons?
- What are the next steps to make a path forward on this topic such as a vote?
- What are the blockers and how can they be overcome?
- If you feel very strongly about a particular tool that is not well
received, what about it do you like and are there accommodations that
can be made from the other options?

Wishing for a healthy discussion.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Nicolas George]

Marth64 (12025-01-20):
> These are some options I noticed interest in (in no particular order):
> - Forgejo
> - GitLab
> - Mailing List/Patch Workflow (current solution)

I have already pointed that GitLab is a piece of crap with a track
record of about one emergency release for security reasons per months. I
just had to do one today for the two public instances I am in charge of.

Can you vouch that Forgejo is not the same?

(Also, me mentioning I am in charge of two public instances of GitLab
does not amount to volunteering to managing a third one, quite the
opposite.)

> - What other options would the community consider and any relevant pros/cons?

Can any of the solution you would favor be used without a
javascript-enabled web browser?

Regards,

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Marth64]

Hi Nicolas,

> Can any of the solution you would favor be used without a
> javascript-enabled web browser?

I'm in this camp too. I also like JS off.
I do not know the correct answer here.
As much as I don't like it, I'd be willing to allowlist the particular
site on my JS blocker if there is not an option.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Nicolas George]

Marth64 (12025-01-20):
> I'm in this camp too. I also like JS off.
> I do not know the correct answer here.
> As much as I don't like it, I'd be willing to allowlist the particular
> site on my JS blocker if there is not an option.

But please, tell me, how do I enable javascript in Perl's
WWW::Mechanize?

Because the issue is not whether to enable or disable js in the web
browser. The issue is whether we can dispense with the web browser
altogether.

But I realize that a js-heavy tool could be as usable as a server-side
tool in that regard, since they are probably designed around a system of
REST APIs: if the APIs are stable and documented and not too convoluted,
that works.

The point I want to make is that the choice of plain Git plus mail for
development is really an absence of choice: let every developer choose
which tools they want to use. Potential FFmpeg contributors are mostly
experienced developers already, they have their own process and favorite
tools. We need a development process that can be made compatible with
their process and tools, whichever they are. With mail, it is possible
and not hard. With big all-in-one online tools, I am not so sure.

Speaking for myself:

I write all my mail in Vim.

I write all my code in Vim.

I write my diary in Vim.

I keep my personal accounts and stewardship in Vim.

I design my t-shirts in Vim.

I make most of my non-trivial graphic compositions in Vim.

I do my 3D modeling in Vim.

When I write something for the web, I am always annoyed by the dilemma
between writing in the crappy built-in editor of the browser and
copy-pasting to and then from Vim.

If I have to use something other than Vim to comment on FFmpeg, then I
will find it annoying and do it less, especially complex answers in
depth.

It is important that our process be compatible with somebody who, same
as me, likes to do everything with Vim. But it is equally important that
our process be compatible with somebody who likes to do everything in
Emacs. Or in VS Code. Or somebody who needs a braille tablet.

It seems to me that goals requires quite a lot of work with all-in-one
online tools, whereas it is automatically achieved with mail.

Regards,

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Marth64]

Hi Nicolas,

This is fine and your preferences are understandable. Everyone has
their tools of choice.

That said, I did try Forgejo on a local instance today without
JavaScript and it was not a usable experience for a contributor.
I could do some limited functions but not raise a PR, for example.
Besides this issue, the experience was pleasant and fast.

Suppose there is an option with simple, reasonably, documented APIs
that can be used to bridge the gaps for our CLI-first developers.
Would you be open to experimenting?
Or as an output from this thread, can we declare what CLI-based user
workflows are needed
for folks to keep their velocity and start there? I imagine a creative
a solution can be found.

Forgejo seems to have this: https://forgejo.org/docs/latest/user/api-usage/
I know from past experience managing a GitLab instance, it has APIs too.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Marth64]

Hi compn:

> i think a good starting off point would be to check all of the
> suggestion options and see how they cohabitate with git-send-mail?
I agree, a breakthrough there could be the most natural on-ramp from
the current flow.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Nicolas George]

Marth64 (12025-01-20):
> This is fine and your preferences are understandable. Everyone has
> their tools of choice.
> 
> That said, I did try Forgejo on a local instance today without
> JavaScript and it was not a usable experience for a contributor.
> I could do some limited functions but not raise a PR, for example.
> Besides this issue, the experience was pleasant and fast.
> 
> Suppose there is an option with simple, reasonably, documented APIs
> that can be used to bridge the gaps for our CLI-first developers.
> Would you be open to experimenting?
> Or as an output from this thread, can we declare what CLI-based user
> workflows are needed
> for folks to keep their velocity and start there? I imagine a creative
> a solution can be found.
> 
> Forgejo seems to have this: https://forgejo.org/docs/latest/user/api-usage/
> I know from past experience managing a GitLab instance, it has APIs too.

As long as the ability to use the solution with command-line tools is
part of the scope statement of the project, I am absolutely fine testing
any kind of solution.

Frankly, it is already refreshing that the preference of people who want
to work in command-line is taken into consideration at all and not just
ignored or treated with scorn, as was so often the case in similar
discussions.

Regards,

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Jan Ekström]

On Wed, Jan 22, 2025 at 2:39 PM Nicolas George <george@nsup.org> wrote:
>
> Marth64 (12025-01-20):
> > This is fine and your preferences are understandable. Everyone has
> > their tools of choice.
> >
> > That said, I did try Forgejo on a local instance today without
> > JavaScript and it was not a usable experience for a contributor.
> > I could do some limited functions but not raise a PR, for example.
> > Besides this issue, the experience was pleasant and fast.
> >
> > Suppose there is an option with simple, reasonably, documented APIs
> > that can be used to bridge the gaps for our CLI-first developers.
> > Would you be open to experimenting?
> > Or as an output from this thread, can we declare what CLI-based user
> > workflows are needed
> > for folks to keep their velocity and start there? I imagine a creative
> > a solution can be found.
> >
> > Forgejo seems to have this: https://forgejo.org/docs/latest/user/api-usage/
> > I know from past experience managing a GitLab instance, it has APIs too.
>
> As long as the ability to use the solution with command-line tools is
> part of the scope statement of the project, I am absolutely fine testing
> any kind of solution.
>
> Frankly, it is already refreshing that the preference of people who want
> to work in command-line is taken into consideration at all and not just
> ignored or treated with scorn, as was so often the case in similar
> discussions.
>

For the record, usage via CLI/e-mail had been brought up by Anton (if
I recall correctly), and the CLI tooling for both Gitlab and
Gitea/Forgejo were looked into.

For Gitlab there is https://gitlab.com/gitlab-org/cli and for Forgejo
the current attempt at a solution seems to be
https://codeberg.org/Cyborus/forgejo-cli (the built-in forgejo-cli
seems to be for maintenance/administrative purposes). Both systems
base on HTTP APIs, so tooling around them can be written.

The initial result from testing was that the Gitlab option had many
more use cases implemented compared to the Forgejo one. Of course, if
such tooling is seen as important enough for FFmpeg's forge usage,
then it may make sense to put resources into developing this tooling
to improve the workflow for those who do not wish to utilize a web
browser.

Best regards,
Jan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Timo Rothenpieler]

On 27.01.2025 21:39, Jan Ekström wrote:
> On Wed, Jan 22, 2025 at 2:39 PM Nicolas George <george@nsup.org> wrote:
>>
>> Marth64 (12025-01-20):
>>> This is fine and your preferences are understandable. Everyone has
>>> their tools of choice.
>>>
>>> That said, I did try Forgejo on a local instance today without
>>> JavaScript and it was not a usable experience for a contributor.
>>> I could do some limited functions but not raise a PR, for example.
>>> Besides this issue, the experience was pleasant and fast.
>>>
>>> Suppose there is an option with simple, reasonably, documented APIs
>>> that can be used to bridge the gaps for our CLI-first developers.
>>> Would you be open to experimenting?
>>> Or as an output from this thread, can we declare what CLI-based user
>>> workflows are needed
>>> for folks to keep their velocity and start there? I imagine a creative
>>> a solution can be found.
>>>
>>> Forgejo seems to have this: https://forgejo.org/docs/latest/user/api-usage/
>>> I know from past experience managing a GitLab instance, it has APIs too.
>>
>> As long as the ability to use the solution with command-line tools is
>> part of the scope statement of the project, I am absolutely fine testing
>> any kind of solution.
>>
>> Frankly, it is already refreshing that the preference of people who want
>> to work in command-line is taken into consideration at all and not just
>> ignored or treated with scorn, as was so often the case in similar
>> discussions.
>>
> 
> For the record, usage via CLI/e-mail had been brought up by Anton (if
> I recall correctly), and the CLI tooling for both Gitlab and
> Gitea/Forgejo were looked into.
> 
> For Gitlab there is https://gitlab.com/gitlab-org/cli and for Forgejo
> the current attempt at a solution seems to be
> https://codeberg.org/Cyborus/forgejo-cli (the built-in forgejo-cli
> seems to be for maintenance/administrative purposes). Both systems
> base on HTTP APIs, so tooling around them can be written.
> 
> The initial result from testing was that the Gitlab option had many
> more use cases implemented compared to the Forgejo one. Of course, if
> such tooling is seen as important enough for FFmpeg's forge usage,
> then it may make sense to put resources into developing this tooling
> to improve the workflow for those who do not wish to utilize a web
> browser.

There is multiple gitea/forgejo cli tools.
The three I know of:
https://gitea.com/gitea/tea
https://codeberg.org/Cyborus/forgejo-cli
https://codeberg.org/VoiDD/fjo

The gitea tea one is probably the by far most feature-complete.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[compn]

On Mon, 20 Jan 2025 23:25:22 +0100, Nicolas George wrote:
> It is important that our process be compatible with somebody who, same
> as me, likes to do everything with Vim. But it is equally important that
> our process be compatible with somebody who likes to do everything in
> Emacs. Or in VS Code. Or somebody who needs a braille tablet.

agree, having the ability to git send mail to any new thing would be
nice.

https://codeberg.org/forgejo/forgejo/issues/4845

i think a good starting off point would be to check all of the
suggestion options and see how they cohabitate with git-send-mail?

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Leo Izen]

On 1/20/25 4:09 PM, Nicolas George wrote:
> Marth64 (12025-01-20):
>> These are some options I noticed interest in (in no particular order):
>> - Forgejo
>> - GitLab
>> - Mailing List/Patch Workflow (current solution)
> 
> I have already pointed that GitLab is a piece of crap with a track
> record of about one emergency release for security reasons per months. I
> just had to do one today for the two public instances I am in charge of.
> 
> Can you vouch that Forgejo is not the same?
> 

Forgejo is a fork of Gitea, and a lot of the code is very similar. 
Notably though it doesn't have any of the for-profit enterprise 
controversy that surrounded Gitea.

I can't vouch for it (or against it, for that matter) but I can say that 
some prominent projects (e.g. Fedora) have chosen it.

- Leo Izen (Traneptora)


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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Michael Niedermayer]

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

Hi

On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
> Hello, in the context of a GA member,
> 
> I think there is general interest in modernizing technical tooling
> specifically regarding ML/patch workflow vs. integrated git solution.
> Both have their merits. I think what we have today is optimized for
> some but cumbersome for many. Like shopping for a drill, it is good to
> step back from time to time and ensure we have the right tools.
> 
> I think the problem statement of productivity being impacted from
> outgrowing the current tooling is different from who is hosting it.
> 
> These are some options I noticed interest in (in no particular order):
> - Forgejo
> - GitLab
> - Mailing List/Patch Workflow (current solution)
> 
> If we evaluate this as choosing a software appliance and put aside
> "who is the host" I think we can have a good discussion. There could
> be value in coming to consensus on one step, then moving on to the
> next.
> 
> The goal is not to spin around on which tool is better but I am wondering,

> - What other options would the community consider and any relevant pros/cons?

I dont know why the options are exclusive. One can add a Forgejo on ffmpeg.org
but leave the Mailing List/Patch Workflow in place for cases where the
maintainer or patch author prefers a ML workflow.

I mean just add an option and see what happens
Who uses it ?
do people submit patches to it ?
do people enjoy working with it ?
do people hate working with it ?

IIUC one can add 1 line to .git/config and then a git fetch will
fetch all pull requests and one can simply merge any without any need of any
browser.

I also dont think we even need a vote to just setup a Forgejo on ffmpeg.org
when it replaces nothing but just adds an option

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire

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

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

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 2:26 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling


> I dont know why the options are exclusive. One can add a Forgejo on
> ffmpeg.org
> but leave the Mailing List/Patch Workflow in place for cases where
> the
> maintainer or patch author prefers a ML workflow.

How is that supposed to work when the contributor is submitting to Forgejo (or whatever) and the maintainer uses the ML?
How do they communicate? 
How does the maintainer get notified that there's a PR available to fetch?
And how does the maintainer comment on code when it wasn't sent to the ML?
Finally, how do the review comments flow back to the modern system?

The only solution I know about which can do this is GitGitGadget (used by the developers of Git itself) which I have adapted and set up (https://github.com/ffstaging/FFmpeg/wiki).
But this is still limited as it doesn't send PR comments back to the ML and it doesn't support mirroring patchsets from the ML back to GitHub and comments from GitHub back to the ML.

Personally though, I'm still quite satisfied with this path as it removes the pain in sending out patch e-mails (and multiple versions) and I can view comments from others nicely on GitHub and in the context of the full files.

There are still so many other advantages in moving away from the ML procedure, but I'll be just watching the discussion from the side this time :-) 

sw 

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Michael Niedermayer]

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

Hi

On Tue, Jan 21, 2025 at 01:56:09AM +0000, Soft Works wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Michael Niedermayer
> > Sent: Tuesday, January 21, 2025 2:26 AM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> 
> 
> > I dont know why the options are exclusive. One can add a Forgejo on
> > ffmpeg.org
> > but leave the Mailing List/Patch Workflow in place for cases where
> > the
> > maintainer or patch author prefers a ML workflow.
> 
> How is that supposed to work when the contributor is submitting to Forgejo (or whatever) and the maintainer uses the ML?

ATM we have contributors who would hapily submit to either and some that only
would submit to one type.
Same for maintainers.
that makes 9 combined cases (ML, ANY, WEB) x (ML, ANY, WEB)
Currently 4 of these 9 cases work

with what i suggest, 7 of 9 would work
If more can be done with smart tools thats great

The goal is to simplify everyones workflow, use all modern tools
available to make it easier for people


> How do they communicate? 

The contributor looks in MAINTAINERS and sees if there is a preferred place to
submit a patch(set) to. If she submits to the wrong place likely people would
help her. Simple patches would get applied complex ones rejected with information
where to submit them.


> How does the maintainer get notified that there's a PR available to fetch?

Iam not sure i understand the question but teh same way as she is notified of
new commits in git, by runnning git fetch and seeing new things


> And how does the maintainer comment on code when it wasn't sent to the ML?
> Finally, how do the review comments flow back to the modern system?
>
> The only solution I know about which can do this is GitGitGadget (used by the developers of Git itself) which I have adapted and set up (https://github.com/ffstaging/FFmpeg/wiki).

cool


> But this is still limited as it doesn't send PR comments back to the ML and it doesn't support mirroring patchsets from the ML back to GitHub and comments from GitHub back to the ML.

cant chatgpt be made to synchronize comments between mailing list and the web?


thx

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

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."

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

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

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 3:38 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> 
> Hi
> 
> On Tue, Jan 21, 2025 at 01:56:09AM +0000, Soft Works wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Michael Niedermayer
> > > Sent: Tuesday, January 21, 2025 2:26 AM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> >
> >
> > > I dont know why the options are exclusive. One can add a Forgejo
> on
> > > ffmpeg.org
> > > but leave the Mailing List/Patch Workflow in place for cases
> where
> > > the
> > > maintainer or patch author prefers a ML workflow.
> >
> > How is that supposed to work when the contributor is submitting to
> Forgejo (or whatever) and the maintainer uses the ML?
> 
> ATM we have contributors who would hapily submit to either and some
> that only
> would submit to one type.
> Same for maintainers.
> that makes 9 combined cases (ML, ANY, WEB) x (ML, ANY, WEB)
> Currently 4 of these 9 cases work
> 
> with what i suggest, 7 of 9 would work

Ah, I got you now. This would mean that one part of patches will never go through the ML and another part will never be seen on "WEB". I hadn't even considered that as a possible/acceptable way, but I wouldn't mind.


> > But this is still limited as it doesn't send PR comments back to
> the ML and it doesn't support mirroring patchsets from the ML back to
> GitHub and comments from GitHub back to the ML.
> 
> cant chatgpt be made to synchronize comments between mailing list and
> the web?

Not unrealistic. The actual process of sending is not the issue, the developers of GGG are hesitant because e-mail conversations are hierarchical and GitHub conversations linear, so unless a message includes a quote from an earlier message it's hard to determine to which ML message the post should be sent as response to.


> if we have Forgejo + ML we can still decide to drop one later and use
> only
> one.
> 
> THis was just a suggestion that seemed easier to agree with for
> everyone
> than a hard switch vs not switch.

It can go without discussion, that's a huge plus indeed :-)

sw



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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Kieran Kunhya via ffmpeg-devel]

>
> Ah, I got you now. This would mean that one part of patches will never go
> through the ML and another part will never be seen on "WEB". I hadn't even
> considered that as a possible/acceptable way, but I wouldn't mind.
>

How is this not confusing as hell for new contributors?

Running two systems concurrently is a recipe for disaster and makes a
difficult process essentially impossible.

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Kieran Kunhya via ffmpeg-devel
> Sent: Tuesday, January 21, 2025 4:57 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Cc: Kieran Kunhya <kieran618@googlemail.com>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> 
> >
> > Ah, I got you now. This would mean that one part of patches will
> never go
> > through the ML and another part will never be seen on "WEB". I
> hadn't even
> > considered that as a possible/acceptable way, but I wouldn't mind.
> >
> 
> How is this not confusing as hell for new contributors?
> 
> Running two systems concurrently is a recipe for disaster and makes a
> difficult process essentially impossible.

It makes sense when considering it a transition phase. (only)

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Marth64]

Kieran:
> Running two systems concurrently is a recipe for disaster and makes a
> difficult process essentially impossible.

I agree this is confusing and unsustainable. There should be only one
"system of record", in a sense.
Are there hooks or simple integration methods we can implement to
mirror content eg. with a python script?

I do think the idea of demoing something is exciting and it can be expanded on.

A little bit of what I was hoping to get from the thread was an
inventory of these needs.

Thanks for pitching in, folks.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Nicolas George]

Michael Niedermayer (12025-01-21):
> The contributor looks in MAINTAINERS and sees if there is a preferred place to
> submit a patch(set) to.

What if the patch series affects areas handled by multiple maintainers?

What if the patch would benefit from the expertise of another developer
than the maintainer?

Having two systems in parallel in practice does not allow anybody to use
only the one they like: in practice it forces everybody to use both.
That is terrible.

Regards,

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[compn]

On Tue, 21 Jan 2025 02:26:24 +0100, Michael Niedermayer wrote:
> I also dont think we even need a vote to just setup a Forgejo on ffmpeg.org
> when it replaces nothing but just adds an option

i agree lets turn on and test these options instead of endlessly
discussing and voting.

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Michael Niedermayer]

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

On Tue, Jan 21, 2025 at 02:26:24AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
> > Hello, in the context of a GA member,
> > 
> > I think there is general interest in modernizing technical tooling
> > specifically regarding ML/patch workflow vs. integrated git solution.
> > Both have their merits. I think what we have today is optimized for
> > some but cumbersome for many. Like shopping for a drill, it is good to
> > step back from time to time and ensure we have the right tools.
> > 
> > I think the problem statement of productivity being impacted from
> > outgrowing the current tooling is different from who is hosting it.
> > 
> > These are some options I noticed interest in (in no particular order):
> > - Forgejo
> > - GitLab
> > - Mailing List/Patch Workflow (current solution)
> > 
> > If we evaluate this as choosing a software appliance and put aside
> > "who is the host" I think we can have a good discussion. There could
> > be value in coming to consensus on one step, then moving on to the
> > next.
> > 
> > The goal is not to spin around on which tool is better but I am wondering,
> 
> > - What other options would the community consider and any relevant pros/cons?
> 
> I dont know why the options are exclusive. One can add a Forgejo on ffmpeg.org
> but leave the Mailing List/Patch Workflow in place for cases where the
> maintainer or patch author prefers a ML workflow.
> 
> I mean just add an option and see what happens
> Who uses it ?
> do people submit patches to it ?
> do people enjoy working with it ?
> do people hate working with it ?

also to elaborate because i have this feeling everything i say lately is
misinterpreted

if we have Forgejo + ML we can still decide to drop one later and use only
one.

THis was just a suggestion that seemed easier to agree with for everyone
than a hard switch vs not switch.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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

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

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

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[James Almer]

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

On 1/20/2025 11:41 PM, Michael Niedermayer wrote:
> On Tue, Jan 21, 2025 at 02:26:24AM +0100, Michael Niedermayer wrote:
>> Hi
>>
>> On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
>>> Hello, in the context of a GA member,
>>>
>>> I think there is general interest in modernizing technical tooling
>>> specifically regarding ML/patch workflow vs. integrated git solution.
>>> Both have their merits. I think what we have today is optimized for
>>> some but cumbersome for many. Like shopping for a drill, it is good to
>>> step back from time to time and ensure we have the right tools.
>>>
>>> I think the problem statement of productivity being impacted from
>>> outgrowing the current tooling is different from who is hosting it.
>>>
>>> These are some options I noticed interest in (in no particular order):
>>> - Forgejo
>>> - GitLab
>>> - Mailing List/Patch Workflow (current solution)
>>>
>>> If we evaluate this as choosing a software appliance and put aside
>>> "who is the host" I think we can have a good discussion. There could
>>> be value in coming to consensus on one step, then moving on to the
>>> next.
>>>
>>> The goal is not to spin around on which tool is better but I am wondering,
>>
>>> - What other options would the community consider and any relevant pros/cons?
>>
>> I dont know why the options are exclusive. One can add a Forgejo on ffmpeg.org
>> but leave the Mailing List/Patch Workflow in place for cases where the
>> maintainer or patch author prefers a ML workflow.
>>
>> I mean just add an option and see what happens
>> Who uses it ?
>> do people submit patches to it ?
>> do people enjoy working with it ?
>> do people hate working with it ?
> 
> also to elaborate because i have this feeling everything i say lately is
> misinterpreted
> 
> if we have Forgejo + ML we can still decide to drop one later and use only
> one.
> 
> THis was just a suggestion that seemed easier to agree with for everyone
> than a hard switch vs not switch.
> 
> thx

I don't think Forgejo's comment section for commits, bugs and MRs is 
good enough for discussion, so i doubt the ML would go anywhere. It will 
just stop being used for patches and reviews as MRs would replace them.


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

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

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> James Almer
> Sent: Tuesday, January 21, 2025 3:57 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> 
> I don't think Forgejo's comment section for commits, bugs and MRs is
> good enough for discussion, so i doubt the ML would go anywhere. It
> will
> just stop being used for patches and reviews as MRs would replace
> them.

Is it not like GitHub where you can add review comments directly at the corresponding code lines?

One essential ability there is that when multiple iterations of patches are sent, you can still see the review comments of the previous version, so you easily see and verify whether it has been resolved. 

Also, when a reviewer has marked a file as reviewed and there's an update to the patchset, the "viewed" marker gets cleared only if the file is different from the last time you reviewed it. That's highly useful as reviewers don't need to go through the whole patchset again on each update.

If you say the discussion would still happen on the ML, how can this work when the code is elsewhere (not on the ML)?

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Niklas Haas]

On Tue, 21 Jan 2025 03:41:06 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
> On Tue, Jan 21, 2025 at 02:26:24AM +0100, Michael Niedermayer wrote:
> > Hi
> >
> > On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
> > > Hello, in the context of a GA member,
> > >
> > > I think there is general interest in modernizing technical tooling
> > > specifically regarding ML/patch workflow vs. integrated git solution.
> > > Both have their merits. I think what we have today is optimized for
> > > some but cumbersome for many. Like shopping for a drill, it is good to
> > > step back from time to time and ensure we have the right tools.
> > >
> > > I think the problem statement of productivity being impacted from
> > > outgrowing the current tooling is different from who is hosting it.
> > >
> > > These are some options I noticed interest in (in no particular order):
> > > - Forgejo
> > > - GitLab
> > > - Mailing List/Patch Workflow (current solution)
> > >
> > > If we evaluate this as choosing a software appliance and put aside
> > > "who is the host" I think we can have a good discussion. There could
> > > be value in coming to consensus on one step, then moving on to the
> > > next.
> > >
> > > The goal is not to spin around on which tool is better but I am wondering,
> >
> > > - What other options would the community consider and any relevant pros/cons?
> >
> > I dont know why the options are exclusive. One can add a Forgejo on ffmpeg.org
> > but leave the Mailing List/Patch Workflow in place for cases where the
> > maintainer or patch author prefers a ML workflow.
> >
> > I mean just add an option and see what happens
> > Who uses it ?
> > do people submit patches to it ?
> > do people enjoy working with it ?
> > do people hate working with it ?
>
> also to elaborate because i have this feeling everything i say lately is
> misinterpreted
>
> if we have Forgejo + ML we can still decide to drop one later and use only
> one.

I think that this makes sense during a planned transition period, to give
everybody enough time to settle into the new system, but it should IMO only be
done with an explicit timeline for when ML submissions will be halted.

>
> THis was just a suggestion that seemed easier to agree with for everyone
> than a hard switch vs not switch.
>
> thx
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> During times of universal deceit, telling the truth becomes a
> revolutionary act. -- George Orwell
> _______________________________________________
> 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".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Frank Plowman]

On 21/01/2025 11:51, Niklas Haas wrote:
> On Tue, 21 Jan 2025 03:41:06 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
>> On Tue, Jan 21, 2025 at 02:26:24AM +0100, Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
>>>> Hello, in the context of a GA member,
>>>>
>>>> I think there is general interest in modernizing technical tooling
>>>> specifically regarding ML/patch workflow vs. integrated git solution.
>>>> Both have their merits. I think what we have today is optimized for
>>>> some but cumbersome for many. Like shopping for a drill, it is good to
>>>> step back from time to time and ensure we have the right tools.
>>>>
>>>> I think the problem statement of productivity being impacted from
>>>> outgrowing the current tooling is different from who is hosting it.
>>>>
>>>> These are some options I noticed interest in (in no particular order):
>>>> - Forgejo
>>>> - GitLab
>>>> - Mailing List/Patch Workflow (current solution)
>>>>
>>>> If we evaluate this as choosing a software appliance and put aside
>>>> "who is the host" I think we can have a good discussion. There could
>>>> be value in coming to consensus on one step, then moving on to the
>>>> next.
>>>>
>>>> The goal is not to spin around on which tool is better but I am wondering,
>>>
>>>> - What other options would the community consider and any relevant pros/cons?
>>>
>>> I dont know why the options are exclusive. One can add a Forgejo on ffmpeg.org
>>> but leave the Mailing List/Patch Workflow in place for cases where the
>>> maintainer or patch author prefers a ML workflow.
>>>
>>> I mean just add an option and see what happens
>>> Who uses it ?
>>> do people submit patches to it ?
>>> do people enjoy working with it ?
>>> do people hate working with it ?
>>
>> also to elaborate because i have this feeling everything i say lately is
>> misinterpreted
>>
>> if we have Forgejo + ML we can still decide to drop one later and use only
>> one.
> 
> I think that this makes sense during a planned transition period, to give
> everybody enough time to settle into the new system, but it should IMO only be
> done with an explicit timeline for when ML submissions will be halted.
> 

+1, although I would perhaps call it a "trial period" rather than a
"transition period".  I think if there is consensus that the forge is
not working when the period comes to a close, then we should not feel
obligated to transition to it.  Instead, we might choose to extend the
period or to return to the ML workflow.  I might even go one step
further and suggest that, if we are to undertake a vote on the
transition, we vote at the end of the trial period.  This way we will
vote with some experience using the forge, rather than speculatively.

In either case, in my mind the duration of such a period is closely
related to how difficult it will be to implement interoperability
between the two systems.  If the period is to be short, we may be
willing to compromise on non-interoperability of some non-essential
features in the interest of avoiding somebody sinking time on a
temporary solution.  On the other hand, if the period is to be long then
we might have more stringent requirements on interoperability.  This
goes the other way also: if investigation indicates it will be difficult
to implement interoperability of some features, then perhaps we should
opt for a shorter period.  There has been some discussion along these
lines already, but if we are to go with a finite transition period, then
I think we need to establish:
* What duration we would like for a transition period.
* A list of features which we would like to interoperate between the
  forge and ML, ideally sorted with some sort of priority.
* How difficult we expect it to be to implement interoperability of the
  aforementioned features.

I also think we need to have a clear plan in place and roles delegated
regarding spam.  Who is responsible and given the necessary permissions
to remove spam?  Are there automated tools we can use to help us reduce
spam?  What is our plan in the case we are overwhelmed with spam?

-- 
Frank

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Niklas Haas]

On Tue, 21 Jan 2025 18:55:05 +0100 Frank Plowman <post@frankplowman.com> wrote:
> On 21/01/2025 11:51, Niklas Haas wrote:
> > On Tue, 21 Jan 2025 03:41:06 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
> >> On Tue, Jan 21, 2025 at 02:26:24AM +0100, Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
> >>>> Hello, in the context of a GA member,
> >>>>
> >>>> I think there is general interest in modernizing technical tooling
> >>>> specifically regarding ML/patch workflow vs. integrated git solution.
> >>>> Both have their merits. I think what we have today is optimized for
> >>>> some but cumbersome for many. Like shopping for a drill, it is good to
> >>>> step back from time to time and ensure we have the right tools.
> >>>>
> >>>> I think the problem statement of productivity being impacted from
> >>>> outgrowing the current tooling is different from who is hosting it.
> >>>>
> >>>> These are some options I noticed interest in (in no particular order):
> >>>> - Forgejo
> >>>> - GitLab
> >>>> - Mailing List/Patch Workflow (current solution)
> >>>>
> >>>> If we evaluate this as choosing a software appliance and put aside
> >>>> "who is the host" I think we can have a good discussion. There could
> >>>> be value in coming to consensus on one step, then moving on to the
> >>>> next.
> >>>>
> >>>> The goal is not to spin around on which tool is better but I am wondering,
> >>>
> >>>> - What other options would the community consider and any relevant pros/cons?
> >>>
> >>> I dont know why the options are exclusive. One can add a Forgejo on ffmpeg.org
> >>> but leave the Mailing List/Patch Workflow in place for cases where the
> >>> maintainer or patch author prefers a ML workflow.
> >>>
> >>> I mean just add an option and see what happens
> >>> Who uses it ?
> >>> do people submit patches to it ?
> >>> do people enjoy working with it ?
> >>> do people hate working with it ?
> >>
> >> also to elaborate because i have this feeling everything i say lately is
> >> misinterpreted
> >>
> >> if we have Forgejo + ML we can still decide to drop one later and use only
> >> one.
> >
> > I think that this makes sense during a planned transition period, to give
> > everybody enough time to settle into the new system, but it should IMO only be
> > done with an explicit timeline for when ML submissions will be halted.
> >
>
> +1, although I would perhaps call it a "trial period" rather than a
> "transition period".  I think if there is consensus that the forge is
> not working when the period comes to a close, then we should not feel
> obligated to transition to it.  Instead, we might choose to extend the
> period or to return to the ML workflow.  I might even go one step
> further and suggest that, if we are to undertake a vote on the
> transition, we vote at the end of the trial period.  This way we will
> vote with some experience using the forge, rather than speculatively.

+1

>
> In either case, in my mind the duration of such a period is closely
> related to how difficult it will be to implement interoperability
> between the two systems.  If the period is to be short, we may be
> willing to compromise on non-interoperability of some non-essential
> features in the interest of avoiding somebody sinking time on a
> temporary solution.  On the other hand, if the period is to be long then
> we might have more stringent requirements on interoperability.  This
> goes the other way also: if investigation indicates it will be difficult
> to implement interoperability of some features, then perhaps we should
> opt for a shorter period.  There has been some discussion along these
> lines already, but if we are to go with a finite transition period, then

In the worst case of zero interoperability, this will simply require
maintainers to check both the forge *and* the ML for patches for a given
period of time. And given that one can simply set up e-mail notifications
for the web forge, the overhead of this is not particularly high.

I don't see the added value of wasting time on implementing a temporary
solution for a non-existent or marginal problem.

> I think we need to establish:
> * What duration we would like for a transition period.
> * A list of features which we would like to interoperate between the
>   forge and ML, ideally sorted with some sort of priority.
> * How difficult we expect it to be to implement interoperability of the
>   aforementioned features.
>
> I also think we need to have a clear plan in place and roles delegated
> regarding spam.  Who is responsible and given the necessary permissions
> to remove spam?  Are there automated tools we can use to help us reduce
> spam?  What is our plan in the case we are overwhelmed with spam?
>
> --
> Frank
>
> _______________________________________________
> 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".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Niklas Haas]

On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net> wrote:
> Hello, in the context of a GA member,
>
> I think there is general interest in modernizing technical tooling
> specifically regarding ML/patch workflow vs. integrated git solution.
> Both have their merits. I think what we have today is optimized for
> some but cumbersome for many. Like shopping for a drill, it is good to
> step back from time to time and ensure we have the right tools.
>
> I think the problem statement of productivity being impacted from
> outgrowing the current tooling is different from who is hosting it.
>
> These are some options I noticed interest in (in no particular order):
> - Forgejo
> - GitLab
> - Mailing List/Patch Workflow (current solution)

Since our last discussion at VDD, I have come to prefer Forgejo over GitLab
and would be in favor of hosting an instance on ffmpeg.org.

What are the current barriers to doing this. Michael, since you said that you
are in favor iff the community agrees with it, should we start a GA vote on
the matter?

Can Timo set it up and maintain it for us? If not, I can also volunteer myself
to do it.

>
> If we evaluate this as choosing a software appliance and put aside
> "who is the host" I think we can have a good discussion. There could
> be value in coming to consensus on one step, then moving on to the
> next.
>
> The goal is not to spin around on which tool is better but I am wondering,
> - What other options would the community consider and any relevant pros/cons?

One pro about ForgeJo is that unlike most of its competitors, it is a community
run project with a democratic governance model, a high degree of transparency
on infrastructure and process, and a commitment to fully open source software
(GPLv3+).

This gives me high hopes that it will be a more stable and reliable platform
than its competitors which seem prone to rug-pulls and feature upselling by
their profit-motivated centralized leadership structures.

> - What are the next steps to make a path forward on this topic such as a vote?
> - What are the blockers and how can they be overcome?
> - If you feel very strongly about a particular tool that is not well
> received, what about it do you like and are there accommodations that
> can be made from the other options?
>
> Wishing for a healthy discussion.
> _______________________________________________
> 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".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Lynne]

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



On 21/01/2025 21:04, Niklas Haas wrote:
> On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net> wrote:
>> Hello, in the context of a GA member,
>>
>> I think there is general interest in modernizing technical tooling
>> specifically regarding ML/patch workflow vs. integrated git solution.
>> Both have their merits. I think what we have today is optimized for
>> some but cumbersome for many. Like shopping for a drill, it is good to
>> step back from time to time and ensure we have the right tools.
>>
>> I think the problem statement of productivity being impacted from
>> outgrowing the current tooling is different from who is hosting it.
>>
>> These are some options I noticed interest in (in no particular order):
>> - Forgejo
>> - GitLab
>> - Mailing List/Patch Workflow (current solution)
> 
> Since our last discussion at VDD, I have come to prefer Forgejo over GitLab
> and would be in favor of hosting an instance on ffmpeg.org.
> 
> What are the current barriers to doing this. Michael, since you said that you
> are in favor iff the community agrees with it, should we start a GA vote on
> the matter?
> 
> Can Timo set it up and maintain it for us? If not, I can also volunteer myself
> to do it.
> 
>>
>> If we evaluate this as choosing a software appliance and put aside
>> "who is the host" I think we can have a good discussion. There could
>> be value in coming to consensus on one step, then moving on to the
>> next.
>>
>> The goal is not to spin around on which tool is better but I am wondering,
>> - What other options would the community consider and any relevant pros/cons?
> 
> One pro about ForgeJo is that unlike most of its competitors, it is a community
> run project with a democratic governance model, a high degree of transparency
> on infrastructure and process, and a commitment to fully open source software
> (GPLv3+).
> 
> This gives me high hopes that it will be a more stable and reliable platform
> than its competitors which seem prone to rug-pulls and feature upselling by
> their profit-motivated centralized leadership structures.
> 
>> - What are the next steps to make a path forward on this topic such as a vote?
>> - What are the blockers and how can they be overcome?
>> - If you feel very strongly about a particular tool that is not well
>> received, what about it do you like and are there accommodations that
>> can be made from the other options?
>>
>> Wishing for a healthy discussion.


Normally, I would rather we switch instantly from ML to whatever we 
pick. But with so many wishing to test working with both systems for a 
transitional period of time, I think there's a viable path unlike 
previous discussions, and the only barrier is simply hosting.

I did volunteer to admin a Forgejo instance during VDD, and if there's 
agreement to setup an instance we can play around with, whether it be on 
ffmpeg.org or on my VPS, I'd be happy to set one up and give people access.
If the tests go fine, we could direct new users to register and submit 
patches on the platform. Email users could subscribe to receive 
notifications and respond, even if full reviews purely over email would 
not be possible.

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

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

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

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Michael Niedermayer]

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

Hi

On Tue, Jan 21, 2025 at 01:04:45PM +0100, Niklas Haas wrote:
> On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net> wrote:
> > Hello, in the context of a GA member,
> >
> > I think there is general interest in modernizing technical tooling
> > specifically regarding ML/patch workflow vs. integrated git solution.
> > Both have their merits. I think what we have today is optimized for
> > some but cumbersome for many. Like shopping for a drill, it is good to
> > step back from time to time and ensure we have the right tools.
> >
> > I think the problem statement of productivity being impacted from
> > outgrowing the current tooling is different from who is hosting it.
> >
> > These are some options I noticed interest in (in no particular order):
> > - Forgejo
> > - GitLab
> > - Mailing List/Patch Workflow (current solution)
> 
> Since our last discussion at VDD, I have come to prefer Forgejo over GitLab
> and would be in favor of hosting an instance on ffmpeg.org.
> 

> What are the current barriers to doing this. Michael, since you said that you
> are in favor iff the community agrees with it, should we start a GA vote on
> the matter?

I would instead of a secret GA vote, maybe wait a few days for discussion
to settle down and then just ask people on the ML about (yes vs no) (strong vs weak)
and a short paragraph about a switch to Forgejo

As well as a 2nd question:
namely on the threshold
should we switch if we have 51% ? or no strong opposition ? or how to draw
the line?
Also, should we switch if we loose some developers by doing so?

Its possible that will give us a clear consensus already
If not, taking another look at the comments from people strongly
opposing in context of yes/no votes in general seems worthy.

Either way i think if this ends with 45% vs 55% i would feel uneasy
I would like to see a clear preferrance of the community, something like
20% vs 80%.

I think a simple count of yes/no strong/weak and what threshold people prefer
seems enough and it seems like "richer" in information.
If this doesnt work out we can just try again in 3 months and if it fails again
we can still go for some hard formal vote. And maybe by the time we will have
cleared up some of the governance disagreements


> 
> Can Timo set it up and maintain it for us?

IIUC timo can do it but he should reply himself i think

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway

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

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

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 4:54 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> 
> Hi
> 
> On Tue, Jan 21, 2025 at 01:04:45PM +0100, Niklas Haas wrote:
> > On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net>
> wrote:
> > > Hello, in the context of a GA member,
> > >
> > > I think there is general interest in modernizing technical
> tooling
> > > specifically regarding ML/patch workflow vs. integrated git
> solution.
> > > Both have their merits. I think what we have today is optimized
> for
> > > some but cumbersome for many. Like shopping for a drill, it is
> good to
> > > step back from time to time and ensure we have the right tools.
> > >
> > > I think the problem statement of productivity being impacted from
> > > outgrowing the current tooling is different from who is hosting
> it.
> > >
> > > These are some options I noticed interest in (in no particular
> order):
> > > - Forgejo
> > > - GitLab
> > > - Mailing List/Patch Workflow (current solution)
> >
> > Since our last discussion at VDD, I have come to prefer Forgejo
> over GitLab
> > and would be in favor of hosting an instance on ffmpeg.org.
> >
> 
> > What are the current barriers to doing this. Michael, since you
> said that you
> > are in favor iff the community agrees with it, should we start a GA
> vote on
> > the matter?
> 
> I would instead of a secret GA vote, maybe wait a few days for
> discussion
> to settle down and then just ask people on the ML about (yes vs no)
> (strong vs weak)
> and a short paragraph about a switch to Forgejo

Isn't this intrinsically biased in the first place?
Asking on the mailing list about who wants to move away from it?

And then telling those who do not like or regularly use the mailing list: "Of sorry, you missed the opportunity of voicing your opinion on moving away from the ML because you didn't read the ML!"

During the time when I didn't follow the ML, I still received and got attention of the voting e-mails. I don't think that an informal call on the ML is suitable for getting a representative picture, but an e-mail with a call for voting will reach out to everybody with an equal chance of getting attention.

sw 





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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Soft Works
> Sent: Tuesday, January 21, 2025 5:14 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Michael Niedermayer
> > Sent: Tuesday, January 21, 2025 4:54 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> >
> > Hi
> >
> > On Tue, Jan 21, 2025 at 01:04:45PM +0100, Niklas Haas wrote:
> > > On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net>
> > wrote:
> > > > Hello, in the context of a GA member,
> > > >
> > > > I think there is general interest in modernizing technical
> > tooling
> > > > specifically regarding ML/patch workflow vs. integrated git
> > solution.
> > > > Both have their merits. I think what we have today is optimized
> > for
> > > > some but cumbersome for many. Like shopping for a drill, it is
> > good to
> > > > step back from time to time and ensure we have the right tools.
> > > >
> > > > I think the problem statement of productivity being impacted
> from
> > > > outgrowing the current tooling is different from who is hosting
> > it.
> > > >
> > > > These are some options I noticed interest in (in no particular
> > order):
> > > > - Forgejo
> > > > - GitLab
> > > > - Mailing List/Patch Workflow (current solution)
> > >
> > > Since our last discussion at VDD, I have come to prefer Forgejo
> > over GitLab
> > > and would be in favor of hosting an instance on ffmpeg.org.
> > >
> >
> > > What are the current barriers to doing this. Michael, since you
> > said that you
> > > are in favor iff the community agrees with it, should we start a
> GA
> > vote on
> > > the matter?
> >
> > I would instead of a secret GA vote, maybe wait a few days for
> > discussion
> > to settle down and then just ask people on the ML about (yes vs no)
> > (strong vs weak)
> > and a short paragraph about a switch to Forgejo
> 
> Isn't this intrinsically biased in the first place?
> Asking on the mailing list about who wants to move away from it?
> 
> And then telling those who do not like or regularly use the mailing
> list: "Of sorry, you missed the opportunity of voicing your opinion
> on moving away from the ML because you didn't read the ML!"
> 
> During the time when I didn't follow the ML, I still received and got
> attention of the voting e-mails. I don't think that an informal call
> on the ML is suitable for getting a representative picture, but an e-
> mail with a call for voting will reach out to everybody with an equal
> chance of getting attention.

Just read December and feel like an idiot. I had no idea what has happened. My interest is better tooling, but now I come to wonder whether this is really just about tooling or possibly other motivations in play. It might make sense to wait until things have settled a bit and people can talk normally to each other again? Not that the transition will end up as a fork.. 

sw 



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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Marth64]

Hi Soft Works,

> I come to wonder whether this is really just about tooling
My post and intent is only about tooling.

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Marth64
> Sent: Wednesday, January 22, 2025 2:08 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> 
> Hi Soft Works,
> 
> > I come to wonder whether this is really just about tooling
> My post and intent is only about tooling.

:-)

It's a bit difficult to judge those repo providers without appropriate data, so I made copies of the ffstaging GitHub site (for creating PRs being sent to the ML), so the all have current ffmpeg data:


Gitea

https://gitea.com/ffstaging/FFmpeg 


forgejo

https://v10.next.forgejo.org/ffstaging/FFmpeg


GitLab

https://gitlab.com/ffstaging/FFmpeg


PRs were copied to forgejo and GitLab, failed for Gitea

Feel free to play around as much as you like, it doesn't matter.
(just not on the origin site https://github.com/ffstaging/FFmpeg) 



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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[martin schitter]

On 22.01.25 03:00, Soft Works wrote:
> It's a bit difficult to judge those repo providers without appropriate data, so I made copies of the ffstaging GitHub site (for creating PRs being sent to the ML), so the all have current ffmpeg data:
> 
> 
> Gitea
> 
> https://gitea.com/ffstaging/FFmpeg
> 
> 
> forgejo
> 
> https://v10.next.forgejo.org/ffstaging/FFmpeg
> 
> 
> GitLab
> 
> https://gitlab.com/ffstaging/FFmpeg


Perhaps you should also add a `radicle` (https://radicle.xyz/) test repo 
to the play, because it's one of the rare solutions, which takes 
decentralization, platform independent meta info within the git repo 
data itself and access by various means really serious. And it's core 
isn't based on one of this horrible web tech frameworks but using rust 
for a perfomance and safety critical server implementation. Only the 
web-browser-frontend uses svelte. Unfortunately it's still in very early 
development stage and hard to get used for newcomers.

In regard to the other three more common choices, you should definitely 
also ask about their CI, search and federation capabilities and current 
support.

Forgejo may look nice on first sight, because it's more or less just 
copying GitHub, which most of us became used over time, but it has a lot 
of really insufficient solved edges, which are very annoying in daily work.

Whenever I contribute to a codberg.org based project, I have to use some 
GitHub mirror in parallel, because the current search capabilities are 
so much worse in Forgjo. You may argue, that searching is a task, which 
you handle localy in your IDE or by old-fashioned command line tools 
anyway. But this will work only for code and commit content! All the 
info, which is placed in issue and merge request threads, isn't easily 
accessibly by other means. If you have to make changes in huge projects, 
you always spend lots of time to understand the history and decisions 
during the development process in the past. This info is usually placed 
in exactly this hidden corners, if available at all, just as here on 
this mailing list.

Better CI support, which is the strong side of GitLab, is IMHO just 
similar important as pure git repo hosting. It helps to automatically 
check merge requests, and report and step by step correcting the related 
issues in a significant more efficient way than here on the list. But 
good CI solutions, which are not just somehow glued together with the 
code management infrastructure, allow much more! They are not controlled 
and configured only by the repo owner by hidden setups, but are 
transparent and can be easily modified by users in their private forks 
or runners on their local machines. That's a very important feature in 
practice, because it motivates developers to also improve this test and 
build infrastructure together instead of just relaying on some 
non-transparent given infrastructure maintained by a few professionals.

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Soft Works]

Hi,

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> martin schitter
> Sent: Wednesday, January 22, 2025 7:42 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> 
> 
> 
> On 22.01.25 03:00, Soft Works wrote:
> > It's a bit difficult to judge those repo providers without
> appropriate data, so I made copies of the ffstaging GitHub site (for
> creating PRs being sent to the ML), so the all have current ffmpeg
> data:
> >
> >
> > Gitea
> >
> > https://gitea.com/ffstaging/FFmpeg
> >
> >
> > forgejo
> >
> > https://v10.next.forgejo.org/ffstaging/FFmpeg
> >
> >
> > GitLab
> >
> > https://gitlab.com/ffstaging/FFmpeg
> 
> 
> Perhaps you should also add a `radicle` (https://radicle.xyz/) test
> repo

This was nothing official nor planned, I just wanted to take a look at forgejo and got it going to quickly that I did the other two as well and posted the links to allow taking a look for those who like to. The "real thing" will be set up by others.

> to the play, because it's one of the rare solutions, which takes
> decentralization, platform independent meta info within the git repo
> data itself and access by various means really serious. And it's core
> isn't based on one of this horrible web tech frameworks but using
> rust
> for a perfomance and safety critical server implementation. Only the
> web-browser-frontend uses svelte. Unfortunately it's still in very
> early
> development stage and hard to get used for newcomers.

From the radicle website:

> For now, Radicle only works on Linux, macOS and BSD variants.

Besides, the intention is to make ffmpeg more accessible to developers rather than less. :-)


> Forgejo may look nice on first sight, because it's more or less just
> copying GitHub, which most of us became used over time, but it has a
> lot
> of really insufficient solved edges, which are very annoying in daily
> work.
> 
> Whenever I contribute to a codberg.org based project, I have to use
> some
> GitHub mirror in parallel, because the current search capabilities
> are
> so much worse in Forgjo. You may argue, that searching is a task,
> which
> you handle localy in your IDE or by old-fashioned command line tools
> anyway. But this will work only for code and commit content! All the
> info, which is placed in issue and merge request threads, isn't
> easily accessibly by other means. 

In the test repo I was able to search code, PR discussions and issue
conversations. What else you looking?

The only bit that I'm sometimes missing is an easy way to find the corresponding pull request discussion for a certain commit, but even GitHub doesn't help with that.


> Better CI support, which is the strong side of GitLab, is IMHO just
> similar important as pure git repo hosting. It helps to automatically
> check merge requests, and report and step by step correcting the
> related
> issues in a significant more efficient way than here on the list. But
> good CI solutions, which are not just somehow glued together with the
> code management infrastructure, allow much more! They are not
> controlled
> and configured only by the repo owner by hidden setups, but are
> transparent and can be easily modified by users in their private
> forks
> or runners on their local machines. That's a very important feature
> in
> practice, because it motivates developers to also improve this test
> and
> build infrastructure together instead of just relaying on some
> non-transparent given infrastructure maintained by a few
> professionals.

I believe that both is required:


1. Automated build and test runs

This is something that should be possible to run for everybody, both locally and in their forks repositories.
forgejo appears to have also cloned GH Actions where the action definitions are part of the code base.


2. Organizational Automation Tasks

Other types of automation are probably of less interest or make no sense to be run by everybody individually, like for example:

- Extended Platform FATE tests
  Running on platforms other than the usual CI runners run on
- Run additional checks on PRs, like
  - Commit message formatting and style
  - Code style checking
  - Check version bump requirement (if reasonably possible)
  - Check doc change if options change (if possible)
- Auto-determine maintainers and notify/tag them
- Auto-apply tags (like for util, codec, format, tools)

forgejo provides WebHooks for many different events, so even a bot like GGG could be done which reacts to certain "/command" comments in PR discussions. I wouldn't see it as a problem when such things are running elsewhere.

sw










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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[martin schitter]

On 25.01.25 08:54, Soft Works wrote:
>>> Gitea
>>>
>>> https://gitea.com/ffstaging/FFmpeg
>>>
>>>
>>> forgejo
>>>
>>> https://v10.next.forgejo.org/ffstaging/FFmpeg
>>>
>>>
>>> GitLab
>>>
>>> https://gitlab.com/ffstaging/FFmpeg
>>
>>
>> Perhaps you should also add a `radicle` (https://radicle.xyz/) test
>> repo
> 
> This was nothing official nor planned, I just wanted to take a look at forgejo and got it going to quickly that I did the other two as well and posted the links to allow taking a look for those who like to. The "real thing" will be set up by others.


Just mirroring a pure git repo is indeed trivial and easily archived by 
a few clicks in all of these solutions. The troubles and more 
challenging compatibility issues and vendor lock in symptoms will appear 
  later in practical use and will soon make any radical changes and any 
transfer to an alternative solution very difficult.

>  From the radicle website:
> 
>> For now, Radicle only works on Linux, macOS and BSD variants.

Do you really want to host GitLab or Forgejo on Win11 or an Ipad? :)

Access to Web-Interface and more traditional ways of git exchange are 
anyway available on radicle hosted projects as well. It's just not the 
typical Web-First approach and the Web-GUI doesn't look really 
convincing. The development is more concentrated on the core parts and 
the challenges of distributed peering without only one central hosting 
instance. But even the tools required for this kind of usage could be 
easily ported to other platforms, if somebody really wants to spend 
efforts on this task.

> Besides, the intention is to make ffmpeg more accessible to developers rather than less. :-)

Sure, I also see the reasons why radicle will not be accepted by most 
users in its current state. The web-Interface is much to simple and 
inferior compared to the more common choices.

But radicle is definitely the only available example of an alternative 
git based source management solution until now, which somehow mastered 
to solve the requirements of decentralized identity management and 
application independent issue storing within git itself.
All other federation promises prospected by the other alternatives are 
still very far away from any real world implementation and will very 
likely also support only federated networks of very similar software, 
instead of focusing on exchange between more or less arbitrary git based 
platforms.

It's really a pity that the compromisless radicle approach is so much 
different to the expectations of most common users, that it will hardly 
have any chance to compete witch centralized services provided by a few 
big companies or those attempts to just copy the simplicity of their 
web-GUIs.

> In the test repo I was able to search code, PR discussions and issue
> conversations. What else you looking?

Yes, on first look it seems to work similar...

But in the case of F. you have to make two or three individual search 
requests if you really want to cover code, Issues and PR comments. And 
in all of them you have to always spend a few more clumsy clicks to 
change the search mode to “exact” and sort by “recently updated” anytime 
again before you finally get a somehow useful list of search result. 
These are the really annoying details in practice, which drive you crazy 
after a while.


>> Better CI support, which is the strong side of GitLab, is IMHO just
>> similar important as pure git repo hosting. It helps to automatically
>> check merge requests, and report and step by step correcting the
>> related
>> issues in a significant more efficient way than here on the list. But
>> good CI solutions, which are not just somehow glued together with the
>> code management infrastructure, allow much more! They are not
>> controlled
>> and configured only by the repo owner by hidden setups, but are
>> transparent and can be easily modified by users in their private
>> forks
>> or runners on their local machines. That's a very important feature
>> in
>> practice, because it motivates developers to also improve this test
>> and
>> build infrastructure together instead of just relaying on some
>> non-transparent given infrastructure maintained by a few
>> professionals.
> 
> I believe that both is required:
> 
> 1. Automated build and test runs

Yes -- I agree. But the tools have to be well integrated into the whole 
system, otherwise it doesn't help to establish a more efficient handling 
of merge requests.

> forgejo appears to have also cloned GH Actions where the action definitions are part of the code base.

Forgejos CI implementation is still in a very early and inferior stage. 
I wouldn't see it as a serious alternative to GitLab in any respect. But 
the very container and Kubernetes focused approach of GitLab also has 
its drawbacks. It's just very powerful and mature in comparison.

> 2. Organizational Automation Tasks
> 
> Other types of automation are probably of less interest or make no sense to be run by everybody individually, like for example:
> 
> - Extended Platform FATE tests
>    Running on platforms other than the usual CI runners run on
> - Run additional checks on PRs, like
>    - Commit message formatting and style
>    - Code style checking
>    - Check version bump requirement (if reasonably possible)
>    - Check doc change if options change (if possible)
> - Auto-determine maintainers and notify/tag them
> - Auto-apply tags (like for util, codec, format, tools)

It's hard to say, which tasks should be actually handled by mechanism 
provided by one of this Git related CI/CD solutions. Vendor lock in 
happens very quickly, and it's always very hard to find a satisfying 
balance between independent tooling and sufficient system integration.

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Marth64]

Hello,

Just wanted to say thank you to everyone for participating, proposing
ideas, and even spinning up demo systems.

It's refreshing to see collective rallying and interest toward a goal.

We still have a ways to figure out details, but I think this is a
positive moment of collaboration.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[James Almer]

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

On 1/21/2025 12:54 PM, Michael Niedermayer wrote:
> Hi
> 
> On Tue, Jan 21, 2025 at 01:04:45PM +0100, Niklas Haas wrote:
>> On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net> wrote:
>>> Hello, in the context of a GA member,
>>>
>>> I think there is general interest in modernizing technical tooling
>>> specifically regarding ML/patch workflow vs. integrated git solution.
>>> Both have their merits. I think what we have today is optimized for
>>> some but cumbersome for many. Like shopping for a drill, it is good to
>>> step back from time to time and ensure we have the right tools.
>>>
>>> I think the problem statement of productivity being impacted from
>>> outgrowing the current tooling is different from who is hosting it.
>>>
>>> These are some options I noticed interest in (in no particular order):
>>> - Forgejo
>>> - GitLab
>>> - Mailing List/Patch Workflow (current solution)
>>
>> Since our last discussion at VDD, I have come to prefer Forgejo over GitLab
>> and would be in favor of hosting an instance on ffmpeg.org.
>>
> 
>> What are the current barriers to doing this. Michael, since you said that you
>> are in favor iff the community agrees with it, should we start a GA vote on
>> the matter?
> 
> I would instead of a secret GA vote, maybe wait a few days for discussion
> to settle down and then just ask people on the ML about (yes vs no) (strong vs weak)
> and a short paragraph about a switch to Forgejo

We can always start a Condorcet vote where the requirement is that only 
non-anonymous votes are considered, if you think that will help (Maybe 
it can even be forced to actually cast your vote?). A vote using mail 
replies in a thread with yes/no is hard to follow.

Also, the vote can happen after a thread with replies stating support 
for one or another solution, with optional argumentation if there's 
something to say that hasn't been said already.

> 
> As well as a 2nd question:
> namely on the threshold
> should we switch if we have 51% ? or no strong opposition ? or how to draw
> the line?

Ideally, there would be two votes. One to open the question if we move 
away from ML patches, and then one to choose between Forgejo/Gitlab, if 
the first vote succeeds. But i don't know if people will be ok with that.

> Also, should we switch if we loose some developers by doing so?
> 
> Its possible that will give us a clear consensus already
> If not, taking another look at the comments from people strongly
> opposing in context of yes/no votes in general seems worthy.
> 
> Either way i think if this ends with 45% vs 55% i would feel uneasy
> I would like to see a clear preferrance of the community, something like
> 20% vs 80%.
> 
> I think a simple count of yes/no strong/weak and what threshold people prefer
> seems enough and it seems like "richer" in information.
> If this doesnt work out we can just try again in 3 months and if it fails again
> we can still go for some hard formal vote. And maybe by the time we will have
> cleared up some of the governance disagreements
> 
> 
>>
>> Can Timo set it up and maintain it for us?
> 
> IIUC timo can do it but he should reply himself i think
> 
> thx
> 
> [...]
> 
> 
> _______________________________________________
> 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".


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

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

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Michael Niedermayer]

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

Hi James

On Tue, Jan 21, 2025 at 01:22:52PM -0300, James Almer wrote:
> On 1/21/2025 12:54 PM, Michael Niedermayer wrote:
> > Hi
> > 
> > On Tue, Jan 21, 2025 at 01:04:45PM +0100, Niklas Haas wrote:
> > > On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net> wrote:
> > > > Hello, in the context of a GA member,
> > > > 
> > > > I think there is general interest in modernizing technical tooling
> > > > specifically regarding ML/patch workflow vs. integrated git solution.
> > > > Both have their merits. I think what we have today is optimized for
> > > > some but cumbersome for many. Like shopping for a drill, it is good to
> > > > step back from time to time and ensure we have the right tools.
> > > > 
> > > > I think the problem statement of productivity being impacted from
> > > > outgrowing the current tooling is different from who is hosting it.
> > > > 
> > > > These are some options I noticed interest in (in no particular order):
> > > > - Forgejo
> > > > - GitLab
> > > > - Mailing List/Patch Workflow (current solution)
> > > 
> > > Since our last discussion at VDD, I have come to prefer Forgejo over GitLab
> > > and would be in favor of hosting an instance on ffmpeg.org.
> > > 
> > 
> > > What are the current barriers to doing this. Michael, since you said that you
> > > are in favor iff the community agrees with it, should we start a GA vote on
> > > the matter?
> > 
> > I would instead of a secret GA vote, maybe wait a few days for discussion
> > to settle down and then just ask people on the ML about (yes vs no) (strong vs weak)
> > and a short paragraph about a switch to Forgejo
> 
> We can always start a Condorcet vote where the requirement is that only
> non-anonymous votes are considered, if you think that will help (Maybe it
> can even be forced to actually cast your vote?). A vote using mail replies
> in a thread with yes/no is hard to follow.

we can force non anonymous voting, this isnt the main concern


> 
> Also, the vote can happen after a thread with replies stating support for
> one or another solution, with optional argumentation if there's something to
> say that hasn't been said already.
> 
> > 
> > As well as a 2nd question:
> > namely on the threshold
> > should we switch if we have 51% ? or no strong opposition ? or how to draw
> > the line?
> 
> Ideally, there would be two votes. One to open the question if we move away
> from ML patches, and then one to choose between Forgejo/Gitlab, if the first
> vote succeeds. But i don't know if people will be ok with that.

that can be done too or a condorcet of gitlab/Forgejo/ML patches can be done

my concern is that the community is not just 49 people.

and before people attack me. the choice of Forgejo/gitlab/git send email affects
many more than 49 people. Every person submiting a patch or contribution is
affected. In fact everyone on ffmpeg-devel is bascially

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.

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

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

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[James Almer]

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

On 1/21/2025 2:48 PM, Michael Niedermayer wrote:
> Hi James
> 
> On Tue, Jan 21, 2025 at 01:22:52PM -0300, James Almer wrote:
>> On 1/21/2025 12:54 PM, Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Tue, Jan 21, 2025 at 01:04:45PM +0100, Niklas Haas wrote:
>>>> On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net> wrote:
>>>>> Hello, in the context of a GA member,
>>>>>
>>>>> I think there is general interest in modernizing technical tooling
>>>>> specifically regarding ML/patch workflow vs. integrated git solution.
>>>>> Both have their merits. I think what we have today is optimized for
>>>>> some but cumbersome for many. Like shopping for a drill, it is good to
>>>>> step back from time to time and ensure we have the right tools.
>>>>>
>>>>> I think the problem statement of productivity being impacted from
>>>>> outgrowing the current tooling is different from who is hosting it.
>>>>>
>>>>> These are some options I noticed interest in (in no particular order):
>>>>> - Forgejo
>>>>> - GitLab
>>>>> - Mailing List/Patch Workflow (current solution)
>>>>
>>>> Since our last discussion at VDD, I have come to prefer Forgejo over GitLab
>>>> and would be in favor of hosting an instance on ffmpeg.org.
>>>>
>>>
>>>> What are the current barriers to doing this. Michael, since you said that you
>>>> are in favor iff the community agrees with it, should we start a GA vote on
>>>> the matter?
>>>
>>> I would instead of a secret GA vote, maybe wait a few days for discussion
>>> to settle down and then just ask people on the ML about (yes vs no) (strong vs weak)
>>> and a short paragraph about a switch to Forgejo
>>
>> We can always start a Condorcet vote where the requirement is that only
>> non-anonymous votes are considered, if you think that will help (Maybe it
>> can even be forced to actually cast your vote?). A vote using mail replies
>> in a thread with yes/no is hard to follow.
> 
> we can force non anonymous voting, this isnt the main concern
> 
> 
>>
>> Also, the vote can happen after a thread with replies stating support for
>> one or another solution, with optional argumentation if there's something to
>> say that hasn't been said already.
>>
>>>
>>> As well as a 2nd question:
>>> namely on the threshold
>>> should we switch if we have 51% ? or no strong opposition ? or how to draw
>>> the line?
>>
>> Ideally, there would be two votes. One to open the question if we move away
>> from ML patches, and then one to choose between Forgejo/Gitlab, if the first
>> vote succeeds. But i don't know if people will be ok with that.
> 
> that can be done too or a condorcet of gitlab/Forgejo/ML patches can be done
> 
> my concern is that the community is not just 49 people.
Then please, suggest names for people not currently in it that you think 
should be.


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

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

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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Niklas Haas]

On Tue, 21 Jan 2025 18:48:01 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
> Hi James
>
> On Tue, Jan 21, 2025 at 01:22:52PM -0300, James Almer wrote:
> > On 1/21/2025 12:54 PM, Michael Niedermayer wrote:
> > > Hi
> > >
> > > On Tue, Jan 21, 2025 at 01:04:45PM +0100, Niklas Haas wrote:
> > > > On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net> wrote:
> > > > > Hello, in the context of a GA member,
> > > > >
> > > > > I think there is general interest in modernizing technical tooling
> > > > > specifically regarding ML/patch workflow vs. integrated git solution.
> > > > > Both have their merits. I think what we have today is optimized for
> > > > > some but cumbersome for many. Like shopping for a drill, it is good to
> > > > > step back from time to time and ensure we have the right tools.
> > > > >
> > > > > I think the problem statement of productivity being impacted from
> > > > > outgrowing the current tooling is different from who is hosting it.
> > > > >
> > > > > These are some options I noticed interest in (in no particular order):
> > > > > - Forgejo
> > > > > - GitLab
> > > > > - Mailing List/Patch Workflow (current solution)
> > > >
> > > > Since our last discussion at VDD, I have come to prefer Forgejo over GitLab
> > > > and would be in favor of hosting an instance on ffmpeg.org.
> > > >
> > >
> > > > What are the current barriers to doing this. Michael, since you said that you
> > > > are in favor iff the community agrees with it, should we start a GA vote on
> > > > the matter?
> > >
> > > I would instead of a secret GA vote, maybe wait a few days for discussion
> > > to settle down and then just ask people on the ML about (yes vs no) (strong vs weak)
> > > and a short paragraph about a switch to Forgejo
> >
> > We can always start a Condorcet vote where the requirement is that only
> > non-anonymous votes are considered, if you think that will help (Maybe it
> > can even be forced to actually cast your vote?). A vote using mail replies
> > in a thread with yes/no is hard to follow.
>
> we can force non anonymous voting, this isnt the main concern
>
>
> >
> > Also, the vote can happen after a thread with replies stating support for
> > one or another solution, with optional argumentation if there's something to
> > say that hasn't been said already.

I am in favor of Frank's suggestion above to defer the formal vote until
*after* the trial period.

> >
> > >
> > > As well as a 2nd question:
> > > namely on the threshold
> > > should we switch if we have 51% ? or no strong opposition ? or how to draw
> > > the line?
> >
> > Ideally, there would be two votes. One to open the question if we move away
> > from ML patches, and then one to choose between Forgejo/Gitlab, if the first
> > vote succeeds. But i don't know if people will be ok with that.
>
> that can be done too or a condorcet of gitlab/Forgejo/ML patches can be done
>
> my concern is that the community is not just 49 people.
>
> and before people attack me. the choice of Forgejo/gitlab/git send email affects
> many more than 49 people. Every person submiting a patch or contribution is
> affected. In fact everyone on ffmpeg-devel is bascially

I conjecture that the vast majority of occasional and drive-by contributors
either would not care what platform we use, or will actively prefer a web-based
forge.

In either case, I don't think we need to worry too much about the opinions of
anybody other than active contributors and core maintainers, for which the GA
is a sufficient proxy.

>
> thx
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
> _______________________________________________
> 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".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Regarding Git Tooling

[Rémi Denis-Courmont]

Le tiistaina 21. tammikuuta 2025, 20.14.49 UTC+2 Niklas Haas a écrit :
> On Tue, 21 Jan 2025 18:48:01 +0100 Michael Niedermayer 
<michael@niedermayer.cc> wrote:
> > > Also, the vote can happen after a thread with replies stating support
> > > for
> > > one or another solution, with optional argumentation if there's
> > > something to say that hasn't been said already.
> 
> I am in favor of Frank's suggestion above to defer the formal vote until
> *after* the trial period.

+1

Voting to have a trial seems very weird indeed.

However based on my experience with moving over to Gitlab in other projects, 
it is absolutely essential that simple, concise and functional documentation 
be made available to all developers and reviewers.

The workings may seem obvious to those use to whichever tool is picked, but 
they probably won't be to people used to the CLI or M$Github.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



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

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

Re: [FFmpeg-devel] Regarding Git Tooling

[James Almer]

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

On 1/21/2025 9:04 AM, Niklas Haas wrote:
> On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64@proxyid.net> wrote:
>> Hello, in the context of a GA member,
>>
>> I think there is general interest in modernizing technical tooling
>> specifically regarding ML/patch workflow vs. integrated git solution.
>> Both have their merits. I think what we have today is optimized for
>> some but cumbersome for many. Like shopping for a drill, it is good to
>> step back from time to time and ensure we have the right tools.
>>
>> I think the problem statement of productivity being impacted from
>> outgrowing the current tooling is different from who is hosting it.
>>
>> These are some options I noticed interest in (in no particular order):
>> - Forgejo
>> - GitLab
>> - Mailing List/Patch Workflow (current solution)
> 
> Since our last discussion at VDD, I have come to prefer Forgejo over GitLab
> and would be in favor of hosting an instance on ffmpeg.org.
> 
> What are the current barriers to doing this. Michael, since you said that you
> are in favor iff the community agrees with it, should we start a GA vote on
> the matter?
> 
> Can Timo set it up and maintain it for us? If not, I can also volunteer myself
> to do it.
> 
>>
>> If we evaluate this as choosing a software appliance and put aside
>> "who is the host" I think we can have a good discussion. There could
>> be value in coming to consensus on one step, then moving on to the
>> next.
>>
>> The goal is not to spin around on which tool is better but I am wondering,
>> - What other options would the community consider and any relevant pros/cons?
> 
> One pro about ForgeJo is that unlike most of its competitors, it is a community
> run project with a democratic governance model, a high degree of transparency
> on infrastructure and process, and a commitment to fully open source software
> (GPLv3+).

So, it works. The only thing we're missing is people to stop being 
aggressive to each other. And for that, the CC should act and be swift.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 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".