All,
I will be slowly transitioning to using my name. Nice to meet you again.
Yalda
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@f
Thanks for the ack, pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hello Michael,
On Sun, Jun 15, 2025 at 11:53 AM Michael Niedermayer
wrote:
> The wiki has the huge advantage that people can edit it easily
>
> Editing the docs people have to do a git checkout, edit a file
> with an editor, make a git commit read patch submission rules
> submit a patch to ML or
Jack Lau,
> I indeed did not notice this grammar issue, and I will be more careful next
> time.
No worries at all, the grammar issue was already there. Thanks for the
fix, will push.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.or
On Sun, Jun 15, 2025 at 10:57 AM Kacper Michajlow
wrote:
> Maybe it's time to retire the trac? It is quite slow by design and not
> really actively maintained anymore. Holding onto legacy software
> always increases the burden of maintainability.
I do feel that a good portion of wiki technical do
thanks both
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
LGTM from a readability perspective
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
LGTM, good catch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Just applying some UX polish.
This is to match the lowercase trend of attributes in
the dump string (and similar to chapters).
Signed-off-by: Marth64
---
libavformat/dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index
Signed-off-by: Marth64
---
libavformat/dvdvideodec.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index f92c5ae54a..40f5e0ac95 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -80,7 +80,6 @@ typedef struct
step in).
Zhao's statement about potential server flooding is also valid.
If there's strong opinion from others there I think its worth to hear.
In my eyes someone can accomplish the same effect with changing header
values directly or using curl.
It my also be for legitimate reaso
I apologize that I did not apply this sooner, around that time I had
to detach due to some personal priorities.
Will rebranch, retest, and apply in the next few days.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinf
> I don't have any reason to think or say anything bad about you or other
> members of the CC.
Then I apologize if I misunderstood. I have no issue hearing criticism
of our structures but the comparison to kindergartners came off the
wrong way.
___
ffmp
te to you and others even if we have
disagreements.
Frankly, beyond this example, you have shown to be generally rude,
gatekeeping to others, and are unpleasant to engage with. You also
seem unaware that not all CC matters are handled publicly.
I have no further comment for you.
Sincerely,
Marth64
Hi,
Expanding on Devin's comment,
See the diagram I have created on page 3 of this deck showing the
digital caption embedding and this XDS stream visually:
https://docs.google.com/presentation/d/19_0EIol3xBy-ubyzHG-vw1y8OLOLOaJgHNlgkY2HsB4/edit#slide=id.g32866a10389_0_53
(Rest of the deck is a w
ry of tough messages is broader than just Kieran or this thread.
In fact, it is rampant in the community and will not improve
overnight.
We will continue to assess other complaints in our docket.
Best,
Marth64
___
ffmpeg-devel mailing list
ffmpeg-
mind that not all FFmpeg-devel
subscribers and archive readers actively follow #ffmpeg-devel.
On behalf of the CC,
Best regards,
Marth64
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe
hat's on our agenda this week? what actions
do we need to take? how do we clear roadblocks? what is our north star
for the future?"
Does this help?
Thank you,
Marth64
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mai
continuing to serve the FFmpeg community and
fostering a collaborative and productive environment. Thank you for
your ongoing support and engagement.
On behalf of the CC,
Best regards,
Marth64
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
to the
appropriate official channel.
These situations are complex, and I’m committed to learning and
improving. I can assure you that the CoC was carefully considered in
this case, and I’ll leave it at that.
Best,
Marth64
___
ffmpeg-devel mailing list
Michael,
> I think its safer for the gsoc contributors to only list
> things where there is no disagreement.
Thank you for pondering this and taking the best interest of the
students into account.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
.
Respectfully,
Marth64
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hi Kieran,
> Adding @Cc
Thanks, acknowledged. I will reach out to you guys via the CC email channel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg
I don't think its fair to shoot this down, its a simple but valid tidy up work.
I find typos and such when browsing code distracting and readability
important down the road.
Not everyone's first language is English and grammar correction may
not come instinctively.
Thank you for the contribution J
Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Will push soon
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
On Sun, Feb 9, 2025 at 2:14 PM Soft Works
wrote:
> Numpad alignment 7, LeftMargin=x VertMargin=y
Yeah, that could work. I forgot about margins. I'll play around with it.
Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/m
Partial reply:
FFmpeg's CC decoder is actually pretty decent for pop-on CC
but produces non-compliant ASS that needs postprocessing.
ASS can cover and render the pop-ons quite well, but the fundamental
limitation with representing EIA608 with ASS is that ASS does not
allow arbitrary positioning AN
Hi Devin & Softworks,
I have been working on a slide deck in my spare time with suggestions
and a roadmap to improve general digital Closed Captions support.
I hope to share this with you and the community for feedback in the
next 2 weeks. I meant to wrap it up sooner but had some IRL stuff come
(libavcodec’s definition of AV_CODEC_ID_EIA_608 is a fallacy, it is
actually A/53 Part 4 coding that is passed around with this codec ID,
which can contain multiple sub-streams including EIA-608 and CEA-708)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
Hi, agreed to move on from this thread.
One parting thought, for future readers -- the RCWT muxer in FFmpeg
preserves the A/53 Part 4 coding intact from decoders which provide it
as side data.
So, it would include EIA608 and CEA708 (DTVCC) pairs since the A/53
Part 4 frames from the SEI messages (
Backported to 6.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Added bit: RCWT will preserve more than what the SCC muxer does
You can also convert the RCWT back to SCC with a single EIA608 field
array, again with either tool
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ff
Hey Zach,
Thanks for the additional context.
Embedding in the traditional sense is not available now.
If archival is also a primary goal, have you checked out the RCWT muxer?
This muxer can collect the original EIA608/CEA708 bytes with all
fields, in A53 Part 4 format,
to a preservable file. The
Re: James
> Backporting it is obviously ok, so no need to wait.
Good deal, will take care of it shortly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffm
Planning to backport in 48-72 hours
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hi folks
Zach (Devlist Archive):
Thanks for sharing your experience and I hope a resolution comes out
of it. I encourage you to write this email instead to the ffmpeg-user
list (or possibly TRAC, our bug trucker), which is better suited for
discussing issues like yours.
Let us pivot this conversat
Yes, confirmed
Looks like its only present on 6.1. In 7.0+ it is fixed by
d9f1b321cf58a85518d29c5a3d220d67b1a68b92 (which is the same change)
If there is no objection I'll back port that commit in the next few days.
Thanks Thinh.
___
ffmpeg-devel mailing
Hello,
Yes I can, thanks for sharing that.
Can you share a sample or steps to reproduce?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ..
I meant obscure in the context of running ffmpeg CLI in a short lived
(<1 day) session for the average user.
Nonetheless I am good. Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubsc
The example I was thinking of was if I wanted to look at the logs 2
years later, it would have time zone in case of DST or whatever.
But it's a total obscure stretch case IMO. I'm not advocating for it,
just sharing what I meant with my logic.
(And if someone really needs it later they can make a +
> it would probably also be odd when there's a single white space in-between.
Yes, it would look worse on white background. OK as is, then.
> Why wouldn't it be machine-parsable without those letters?
It is more about having timezone, etc.
I actually think it is better for readability as is, but w
Hello,
Patch fails to apply (looks like a rebase needed since I see the path
of hevcdec.c is older).
Also a sample or context to trigger the condition would be nice to validation.
Thank you
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffm
It works good. First pass thoughts:
1- Rename `timeBuf` -> `bp_time`, in this way it follows snake case
convention and conveys clearly that the parameter is an `AVBPrint`
2- Option switch: +datetime and +time feels lighter/easier (vs. -ing)
3- Term color: the space after the time keeps the backgr
Leo:
> If you do, you should consider not just -nostdin but also if reading
> from stdin like a pipe, e.g. ffmpeg -i - foo.mkv
> this will exit with success if foo.mkv exists without asking on stdin
> (as you'd expect it to not, cause it's reading from stdin)
Agreed, that sounds logical.
I'll
Planning to push in 24-48 hours.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Planning to push in 24-48 hours.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
+ 1 to Leo
I have this card installed and active and can help validate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with
I know `if ((ret = av_do_something()) <0)` pattern has been frowned
upon recently but besides that it LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
> On 2024-07-16 09:40 am, Marth64 wrote:
> > Gyan:
> >> The former is not an error. The user was asked and the application
> >> behaved as per their reply.
> > Could it make sense to only return the AVERROR(EEXIST) if -nostdin is
> > passed (otherwise curr
Thank you Timo for removing the flag.
Now users should be able to join correctly.
Patch LGTM. I don't have access to merge to web.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visi
the seek
operation, and skipping 3 VOBUs (NAV packet led segments) ahead
where dvdnav will have positioned itself correctly.
Reported-by: Kacper Michajlow
Signed-off-by: Marth64
---
libavformat/dvdvideodec.c | 36
1 file changed, 36 insertions(+)
diff
Hi Scott,
LGTM.
I will push soon and fix the APIchanges on the way.
Apologies for the delay on this simple patch.
Had a lot of issues getting the machine up and running.
I was able to capture a sample finally and test this out.
I wanted to test it to get an idea of how EIA-608 travels through th
Currently, if there is a hardware encode failure, the numeric
error code will be printed making it somewhat hard to get to
the root cause of the issue. Print the readable message generated
by av_err2str() instead.
Signed-off-by: Marth64
---
libavcodec/hw_base_encode.c | 5 +++--
1 file changed
LGTM. I'm aligned.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Will push
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Pushing shortly
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hi,
If extended it will have to be more generic. But for only two fields
present now I did not want to over engineer this in the initial
addition of the option.
It makes sense except for the DVB subs. I thought those were discrete
graphics or text streams. Wouldn't analyzeduration catch them?
> What do you think about this?
On first glance it sounds promising. I think it's worth exploring.
I've not used coded_side_data before so I'd have to look again with
fresh eyes to make a better opinion.
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@
That said, the concept of exposing the properties was rejected. I
understand why since they are internal.
So the conversation would have to be re-opened, or maybe an
alternative solution devised.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
> LOL 😊
lol indeed :)
> Another use case is in combination with Subtitle Filtering: If there's
> auto-conversion desired in ffmpeg
Yeah that's reasonable. I would request a manual switch or some other
way to establish the filter unconditionally, for those who do want to
operate on the sparse file
> So, this has to be worked out in some way. Do you want to submit something or
> shall I?
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=12356
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-dev
> Which kind of recurrence pattern are you talking about?
I am talking about really sparse pattern. e.g. nothing for a long
time, then ads inserted or program changes, and embedded bit stream
starts.
It's not that often but it happens with SCTE-20, or sloppy DVD edits
for example.
> Even if it wa
> For what it's worth, I have seen this and it can definitely happen.
Hi, I have seen it too, especially with SCTE-20 samples. Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, v
LGTM. I had noticed that #ffmpeg channel has +r mode but #ffmpeg-devel
does not which can confuse people. So if user does not have registered nick
they will only be loaded into #ffmpeg-devel.
Maybe this gets changed or explained in a second patch later but this is
good enough.
Will push tomorrow. Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hi Nicolas:
> Please do not accept uncritically what a greedy minority limply
> supported by a silent majority wants to pass as the will of the
> community.
Help me understand your version so we can make a table to contrast?
Thanks
___
ffmpeg-devel mail
Hi Kieran:
Trying to distill to a start of discussion points at the high level
(without GPT).
Converting the statements, from (issue)->(Michael) to (issue)->(effect):
* The community wants the GA/TC/CC to be sovereign, but there is a
BDOL model too which is not easily compatible, causing uncertai
Here is an idea,
Can we try to lay out the friction points in a table or bullet format
where we can separate the issue from emotion and direct name calling?
For example,
" * Community has issue ABC but we can't move forward because senior
leaders don't agree"
" * Community has issue XYZ but we can
Hi Soft Works,
> So I apologize for the misunderstanding. I didn't intend to be rude or hurt
> anybody's feelings, I just meant to express for what it's commonly used and
> didn't mean to take the conversation some levels downwards.
It's okay. You're entitled to share your opinion too. I was not
Hello all,
The thread is passionate but I'm requesting help from everyone to
please help me make it more productive than negative.
I agree with Zhao Zhili:
> I don’t stay long enough to know the history, but I don’t think delving into
> history
> helps the current situation. Let's talk less abou
Hi Soft Works,
> What do you mean by "colorful language"?
> And "mockery" - you mean the pseudo code? What's wrong about that? I could
> have said the same in many words as well.
Words are fine and passionate opinions are fine. The pseudocode and
"shit-storming" comment came off the wrong way, th
Hello,
Re: Soft Works
Let's not mock people please. You are entitled to your opinion but we
can leave the colorful language and mockery out.
Not saying you are the first and only one, I am aware this is a
chronic habit for the community email threads at large, but I ask
yourself and everyone for h
> Agreed.
I'm good too, thanks for the input.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hi,
That is what I am imagining when I mean have a meeting, suggesting
that maybe we should try a different communication medium that can be
facilitated more rapidly.
I was thinking an IRC meeting would be more beneficial than email
because email is hard to moderate.
In IRC, there are more easily
Hi Gyan,
> Will the activity of these meetings be recorded and available publicly?
If we have a meeting, I would expect it to be recorded and available
publicly just like here:
https://trac.ffmpeg.org/wiki/FFmeeting/2020-12
Looks like the process was established before :)
_
I am only trying to be a voice of reason.
Please consider if we can have a community IRC meeting or in some other fashion
discuss a framework improvement in a safe space.
I would be happy to put together an agenda.
___
ffmpeg-devel mailing list
ffmpeg-de
not have access
to last year's manifest of issues.
Also like Rémi said, the rest of the team had been busy (which is
fine) so I have been doing my best to cover in the meantime.
I volunteered to do the job so I was not going to just sit by idly.
Thank you,
Marth64
Looks dead to me
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> they are broadcasting using a variation of DVB-S (there is no US standard for
> sat tv), so the current naming is actually valid.
This is my understanding also, but I do believe there was 1 other
network that used the same variation.
Hence why I suggested a generic name. The counter argument fr
Hello,
I am to blame here for suggesting DVB_0502 as the name.
I realize it was not the best choice and apologize for wasting your
cycles on this.
Looping in Keiran as we had discussed this over IRC briefly a few weeks back.
As I don't know how many networks actually use this in the wild, it
coul
mmikuuta 2025, 2.36.47 UTC+2 Michael Niedermayer a écrit
> > :
> > > Hi
> > >
> > > On Mon, Jan 20, 2025 at 10:38:17AM -0600, Marth64 wrote:
> > > > All this time people send back and forth emails attacking each other or
> > > > the
> >
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.
__
Hello,
I would like to call for this thread to dissolve, it's getting ugly.
It's become a swirl of different grievances and the tone is toxic all around.
What is this good for besides draining away energy?
The thread's original scope has been outgrown.
We have some unresolved issues, sure.
Can w
Hello,
Looking forward to it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hi Dale,
LGTM. Will push soon.
Thanks Michael for the quick check.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with su
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
Hi Michael,
> I do think the CC is a problematic entity in a community where there are
> complex friendships and hatred. And then the members of this CC come from this
> small group and mainly judge members of this same group
I am not from this group. I volunteered for the role to help the cultur
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
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.
Hi Nicolas (+),
> Let us add that the camp that wants more stability than originality
> already tried to become the dominant camp in the last years of the 2000s
> decade, with the same strategy of bullying Michael.
Just to reaffirm,
I have no such intention and am not in this camp.
Folks have bee
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
Hi Nicolas,
Re: Tooling
I am suggesting that there can be a middle ground somewhere.
I am not fond of modern heavy web GUIs myself and fully understand
that more senior developers have advanced needs.
The custom tooling I am referring to is Patchwork.
A neat tool, but is this not also a web GUI?
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
Hi, Nicolas George:
> No, we do not.
I disagree.
There are people who have specialty areas.
They are the de facto leaders of their domains.
If you gave me constructive feedback on a patch in your domain, I’d look at
you as a technical thought leader in the space.
There is also a Technical Commi
Hi,
Re: Softworks,
> As a contributor, I'm expecting my contributions to:
> - Not be ignored
> - Receive one of these three responses:
> 1. OK (and get merged in a timely manner)
> 2. No (for whichever reason)
> 3. Ok but needs changes
The contribution is more likely to be ignored or responded
All this time people send back and forth emails attacking each other or the
project could have spent toward investing in modern DevOps infrastructure
or discussing other advancements.
It’s energy-draining to both read and write.
It makes me wonder do folks actually get enjoyment out of the drama?
James Almer:
> I'd really like if we can stop with the "Everything's fucked, nothing
> can be done" mails every other week and instead make use of the
> framework we came up with, or if needed, change it and improve it.
+1
or we will never move forward with anything
__
IMHO (as myself and not representing the CC).
The project already has technical leaders.
The project already has great talent.
The project has some semblance of democratic processes.
The project is hard to work with or seemingly "hostile, non-welcoming"
because we are using ancient workflows that
1 - 100 of 606 matches
Mail list logo
