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

[Rémi Denis-Courmont]

Le keskiviikkona 16. syyskuuta 2020, 9.15.23 EEST Jean-Baptiste Kempf a écrit 
:
> On Wed, 16 Sep 2020, at 07:49, Rémi Denis-Courmont wrote:
> > Le keskiviikkona 16. syyskuuta 2020, 0.04.40 EEST Jean-Baptiste Kempf a
> > écrit> 
> > > > 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.
> 
> Not all the Windows 10 versions support that.
> 
> > > 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).
> 
> But who speaks about VLM?

This thread is a VLM patchset review.

> We want to be able to have the UI the "I want to record this, at this hour".
> We discussed that feature many times.

No, I don't think so. I don't recall many mentions of that on vlc-devel, 
except for the proposal to remove VLM schedules.

> Refactoring the VLM schedules and fixing them can lead to this feature.

Not really, no. For the sake of the argument, lets say that somebody fixes the 
glaring date and time management bugs in schedules, and adds proper 
programmatic interfaces around them and broadcasts, for GUI to use.

Since VLC still does not know how to start automatically and how to manage 
power management, it would still fail for most users. That is to say, most 
users who do have cleartext IPTV. DVB tuners wouldn't realistically work 
because the media library does not support them to date, and the existing 
scanner is not usable by a normal user.

> And especially if that allows to fix broken schedules. But it is not, if
> every patch is bikeshed to death.
> 
> You cannot refuse evolutions, step-by-step, it must be perfect before
> entering the codebase. This is not real life, and this is not VLC.

What VLM schedule evolution did I refuse? I proposed to remove it because it's 
unusable. When that was rejected, I filed the bugs. I've yet to see any 
proposal to fix any of them.

> And features that are removed are 100x times harder to make them back,
> because if must be perfect.

A schedule is 10x easier to implement directly in the Qt GUI than through the 
text-based event-less shared interface that VLM is.

> > 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.
> 
> Then, say "this break log prefixes" and see how we can fix that.

I did that, ~12 hours before you posted this even.

> > The rest is just moving code around at equal complexity, and adding one or
> > two layers of wrappers on the existing code.
> 
> Which is what we said we wanted: remove code from the core, notably parsing
> ones. So that they can be
> 
> > The whole point of a code review process is to reject what is broken/
> > incorrect.
> 
> Yet, the whole VLC is broken and incorrect in so many ways.
> There must be a balance. VLC is an end-user project,

The trade-off in a code review process is that you keep existing features until 
they are unused even if they have known bugs, but you don't merge new features 
with known bugs.

> not a research or a compiler project.

Well I've been in multiple academic and then research projects and there is 
indeed little to no balance there. But that's going the other way around: you 
merge anything and everything no matter how broken.

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