[vlc-devel] [PATCH 00/14] Move VLM implementation to a module

[Rémi Denis-Courmont]

Le keskiviikkona 16. syyskuuta 2020, 0.04.40 EEST Jean-Baptiste Kempf a écrit 
:
> > > You refuse to allow any incremental change
> > 
> > Seriously what the bloody hell? You're the one that rejected the last
> > proposed incremental change to VLM. And *you* have failed to even support
> > your assertions back then, which were ostensibly false.
> 
> Which  proposal?
> 
> > I proposed to remove the completely broken VLM schedules and retain the
> > clunky but mostly not broken VLM broadcasts. I'd still like to know what
> > OS supports VLM and does not support some form of scheduled tasks...
> 
> Numerous versions of Windows 10, for example.

No. There's millions of ways to do this on Windows 10.

> macOS scheduling is very hard to do, for normal users.

It's not as hard as figuring out how to use the VLM schedules (an then figuring 
out how to work around its complete brokeness).

> > > you block moving it outside of the core to make a simpler core
> > 
> > More BS. This patchset is making things more complicated.
> 
> I disagree. It removes parsers from the core and removes a lot of the ifdef
> HAVE_VLM.

You said that removing objectively broken VLM schedules was not acceptable 
because they should be fixed. And here we have a patch that breaks log prefixes, 
and somehow that's okay. Talk about being consistent.

And if it didn't break that, it would actually be making things strictly more 
complicated. Log prefix removal is the only meaningful code simplification in 
the whole patchset.

The rest is just moving code around at equal complexity, and adding one or two 
layers of wrappers on the existing code.

> > > and simpler evolution...
> > 
> > There's no evolution here. All it seems to do is move code around, adding
> > one layer of indirection, and *breaking* the log prefixes.
> 
> Because one need to improve step by step.

Removing the log prefixes is not a step-by-step improvement. This patchset in 
this version is not a step-by-step improvement.

> > > This is going on and on, and not just about VLM, and this is not
> > > acceptable
> > > to me.
> > 
> > What is unacceptable here is your repeated behaviour of throwing false
> > accusations and nonsensical arguments against people (especially but not
> > limited to me) that don't go Your Way.
> 
> That's very rich.
> You reject literally everything that does not fit your view of
> "brokenness/correctness",

The whole point of a code review process is to reject what is broken/
incorrect. If you're not happy with code review happening, I'm not the one to 
blame for mandating them.

Besides, I do tend to use different wording for broken (objective) and bad idea 
/ poor design (subjective). And there are plenty of things that I don't like 
that I tolerate, or don't even comment on.

And I don't have a view of brokeness.

Treating every calendar months as 30 days and every calendar days as 24 hours 
is broken according to the accepted calendar. Waking up at different wall clock 
time than requested when the RTC is adjusted is broken.

Removing the VLC log prefix code is breaking the underlying feature, or if it 
had already regressed, breaking/regressing it even more.

Violating the memory model is broken. I don't make the memory model, and I 
don't make the compilers implementing the memory model.

I do tend to use different wording when it's an empirically or subjectively bad 
idea.

> We've had this discussion over and over and over, over the years. At some
> point, be a force of proposal, and not just rejectsion.

That's pretty rich for somebody who just posts that "[he] disagree[s] about 
removing this feature" [1] as sole rejection review comments.

You're not the only person on this project with time constraints.

[1] https://mailman.videolan.org/pipermail/vlc-devel/2020-August/136776.html

-- 
Реми Дёни-Курмон
http://www.remlab.net/