On 27.01.2025 21:39, Jan Ekström wrote:
On Wed, Jan 22, 2025 at 2:39 PM Nicolas George 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
On Wed, Jan 22, 2025 at 2:39 PM Nicolas George 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 experienc
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.
__
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 plann
Hi,
> -Original Message-
> From: ffmpeg-devel 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:
>
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
wrote:
> > > Also, the vote can happen after a thread with replies stating support
> > > for
> > > one or another solution, with optional argumentation if there's
> > >
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 rai
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
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marth64
> Sent: Wednesday, January 22, 2025 2:08 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
>
> Hi Soft Works,
>
> &
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
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Tuesday, January 21, 2025 5:14 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
>
>
>
> > -Or
On 1/21/2025 9:04 AM, Niklas Haas wrote:
On Mon, 20 Jan 2025 14:39:29 -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 th
On Tue, 21 Jan 2025 18:48:01 +0100 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
On Tue, 21 Jan 2025 18:55:05 +0100 Frank Plowman wrote:
> On 21/01/2025 11:51, Niklas Haas wrote:
> > On Tue, 21 Jan 2025 03:41:06 +0100 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:29P
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 wrote:
Hello,
On 21/01/2025 11:51, Niklas Haas wrote:
> On Tue, 21 Jan 2025 03:41:06 +0100 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,
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 wrote:
> > > > Hello, in the context of a GA memb
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 wrote:
Hello, in the context of a GA member,
I think there is general interest in modernizing technical tooling
specifically regarding
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 4:54 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
>
> Hi
>
> O
Hi
On Tue, Jan 21, 2025 at 01:04:45PM +0100, Niklas Haas wrote:
> On Mon, 20 Jan 2025 14:39:29 -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
On 21/01/2025 21:04, Niklas Haas wrote:
On Mon, 20 Jan 2025 14:39:29 -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 t
On Mon, 20 Jan 2025 14:39:29 -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
On Tue, 21 Jan 2025 03:41:06 +0100 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
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 ma
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
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Kieran Kunhya via ffmpeg-devel
> Sent: Tuesday, January 21, 2025 4:57 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Kieran Kunhya
> Subject: Re: [FFmpeg-devel] Regarding Git
>
> 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 sys
> -Original Message-
> From: ffmpeg-devel 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,
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 3:38 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
>
> Hi
>
> O
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
specifica
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
peg.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
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
__
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 2:26 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Regarding Git Tooling
> I dont know why the op
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 i
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 mailin
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.
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 Cod
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::Mec
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 eme
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 a
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 pe
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
43 matches
Mail list logo
