| Message ID | 20160910212557.6215-1-timo@rothenpieler.org |
|---|---|
| State | Superseded |
| Headers | show |
On 10/09/2016 22:25, Timo Rothenpieler wrote: > [...] > +DEPRECATED_PROGRAM_LIST=" > + ffserver > +" > [...] I don't really see the point of this, the other programs are unlikely to be deprecated soon, and this list will be removed after ffserver is. I think it'd just be best to leave it in PROGRAM_LIST. -- Josh
On 9/10/2016 11:40 PM, Josh de Kock wrote: > On 10/09/2016 22:25, Timo Rothenpieler wrote: >> [...] >> +DEPRECATED_PROGRAM_LIST=" >> + ffserver >> +" >> [...] > > I don't really see the point of this, the other programs are unlikely to > be deprecated soon, and this list will be removed after ffserver is. I > think it'd just be best to leave it in PROGRAM_LIST. It being in PROGRAM_LIST is what enables it by default, as there is an "enable $PROGRAM_LIST". So moving it to another variable is neccessary.
On 10/09/2016 22:50, Timo Rothenpieler wrote: > On 9/10/2016 11:40 PM, Josh de Kock wrote: >> On 10/09/2016 22:25, Timo Rothenpieler wrote: >>> [...] >>> +DEPRECATED_PROGRAM_LIST=" >>> + ffserver >>> +" >>> [...] >> >> I don't really see the point of this, the other programs are unlikely to >> be deprecated soon, and this list will be removed after ffserver is. I >> think it'd just be best to leave it in PROGRAM_LIST. > > It being in PROGRAM_LIST is what enables it by default, as there is an > "enable $PROGRAM_LIST". > So moving it to another variable is neccessary. Oh, sorry, yes I see now. This looks fine then. -- Josh
2016-09-10 23:25 GMT+02:00 Timo Rothenpieler <timo@rothenpieler.org>: > - --disable-ffserver disable ffserver build > + --enable-ffserver enable ffserver build This is not ok and you are not explaining it. Carl Eugen
On 9/11/2016 1:22 AM, Carl Eugen Hoyos wrote: > 2016-09-10 23:25 GMT+02:00 Timo Rothenpieler <timo@rothenpieler.org>: > >> - --disable-ffserver disable ffserver build >> + --enable-ffserver enable ffserver build ffserver is unmaintained for a very long time now. It's been discussed about deprecating or even straight up removing it for a while now. As a first step to actually get somewhere with that, this patch stops building ffserver by default, unless it's explicitly requested via --enable-ffserver. It's not intended to deprecate ffserver (yet), just a signal to users that they really want to switch to/use something else, or pick up maintainership of it.
2016-09-11 1:48 GMT+02:00 Timo Rothenpieler <timo@rothenpieler.org>: > It's not intended to deprecate ffserver (yet), just a signal to users > that they really want to switch to/use something else, or pick up > maintainership of it. A sufficient signal is already on the homepage. Carl Eugen
2016-09-11 2:59 GMT+02:00 Carl Eugen Hoyos <ceffmpeg@gmail.com>: > 2016-09-11 1:48 GMT+02:00 Timo Rothenpieler <timo@rothenpieler.org>: > >> It's not intended to deprecate ffserver (yet), just a signal to users >> that they really want to switch to/use something else, or pick up >> maintainership of it. > > A sufficient signal is already on the homepage. Or actually: Don't you agree that a deprecation message printed by the program would make much more sense? Carl Eugen
On 11/09/16 02:07, Carl Eugen Hoyos wrote: > > Or actually: Don't you agree that a deprecation message printed by > the program would make much more sense? > > Carl Eugen This could interfere with users' current scripts for running ffserver and turn into "adding insult to injury" for the time it is still around.
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit : > This could interfere with users' current scripts for running ffserver and > turn into "adding insult to injury" for the time it is still around. Deprecation messages go to stderr. If users' scripts rely on the format of stderr, breaking them is not insult or injury, it's didactic. Regards,
On 11/09/16 08:39, Nicolas George wrote: > Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit : >> This could interfere with users' current scripts for running ffserver and >> turn into "adding insult to injury" for the time it is still around. > Deprecation messages go to stderr. If users' scripts rely on the format of > stderr, breaking them is not insult or injury, it's didactic. > > Regards, Error messages go to stderr and one sometimes parses these to respond to an error. Excluding it from the default build rules is a good idea. Let the code still be around while it works and only when it proofs it no longer does do you drop it. Who knows when this will be and if not somebody steps up. If you feel strongly about doing something then how about maintaining it?
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
> Error messages go to stderr and one sometimes parses these to respond to an error.
This is bogus and should not be considered a reason for design decisions.
If there are cases where this is actually necessary, then report them and we
can reflect on a correct solution.
Regards,
On 11/09/16 10:45, Nicolas George wrote: > Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit : >> Error messages go to stderr and one sometimes parses these to respond to an error. > This is bogus and should not be considered a reason for design decisions. > > If there are cases where this is actually necessary, then report them and we > can reflect on a correct solution. No, it's not bogus. It's what sometimes must be done. For example, just this morning did I again have to pipe the output of ffprobe through "|&" because it likes to print its findings to stderr and not simply stdout. Not meaning to derail the topic, but to make a point close "to home". All I am really saying is that I don't quite agree with Carl. However seeing how you feel so strongly about what to put into ffserver are you volunteering to become it's new maintainer (... congrats!). If one doesn't want to be its maintainer than I don't see how one can afford to have this opinion. Rather should one follow the general coding rule of FFmpeg to keep changes minimal and to check if these cannot be made even smaller. Sven
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit : > No, it's not bogus. Yes, it is. > It's what sometimes must be done. For example, just this > morning did I again have to pipe the output of ffprobe through "|&" because > it likes to print its findings to stderr and not simply stdout. Not meaning > to derail the topic, but to make a point close "to home". Are you sure you should not have been using ffprobe? > All I am really saying is that I don't quite agree with Carl. However seeing > how you feel so strongly about what to put into ffserver are you > volunteering to become it's new maintainer (... congrats!). I do not care at all about ffserver, but the argument of parsing stderr to revuse a warning is completely void, period. Regards,
On 11/09/16 15:12, Nicolas George wrote: > I do not care at all about ffserver, but the argument of parsing stderr to > revuse a warning is completely void, period. > > Regards, Please no foot stomping of opinions. When you cannot see how changing the output can confuse scripts of users then that's ok, but you then shouldn't act like a child. Show some more maturity, please. Sven
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit : > Please no foot stomping of opinions. When you cannot see how changing the > output can confuse scripts of users then that's ok I see how it can do that, but you refuse to understand that this part of the output is not meant to be parsed, unlike, for example, the output of ffprobe. If some information is only available in stderr output, then we can consider adding a clean solution for that. Please share any precise information you have on the matter. Otherwise, it is just idle handwaving. > but you then shouldn't > act like a child. Show some more maturity, please. I leave to you the responsibility of name calling. Regards,
On Sun, Sep 11, 2016 at 5:04 PM, Sven C. Dack <sven.c.dack@sky.com> wrote: > On 11/09/16 15:12, Nicolas George wrote: >> >> I do not care at all about ffserver, but the argument of parsing stderr to >> revuse a warning is completely void, period. >> >> Regards, > > > Please no foot stomping of opinions. When you cannot see how changing the > output can confuse scripts of users then that's ok, but you then shouldn't > act like a child. Show some more maturity, please. > All the text output of the CLI tools goes to stderr, and we have never considered it to be "stable" for the sake of people that parse arbitrary log output - and nor should we, because that would be a terrible situation to be in if we can't even change, add, or adjust the log output of our tools. - Hendrik
On 11/09/16 16:31, Nicolas George wrote: > I see how it can do that, but you refuse to understand that this part of the > output is not meant to be parsed, unlike, for example, the output of > ffprobe. Nonsense. All messages, regardless if send to stdout or stderr, can be parsed. There is no rule in this world that says you shouldn't or couldn't do so. But regardless of this, when you are no longer maintaining the code then you can also no longer insist on users having to accept the consequences of changes. The change, to print a single message, has no gain to the users who are still using ffserver. They will not thank you for abandoning the program, they may even feel annoyed by the message each time it prints, and as I pointed out before can cause them problems. You really want to leave the code untouched and provide it "as is" until the time it gets dropped. Put the message into configure, put it into the manpage, on the webpages and the --help documentation, but please don't just pop it out onto stderr. Sven
On Sun, Sep 11, 2016 at 06:17:01PM +0100, Sven C. Dack wrote: > On 11/09/16 16:31, Nicolas George wrote: > > I see how it can do that, but you refuse to understand that this part of the > > output is not meant to be parsed, unlike, for example, the output of > > ffprobe. > > Nonsense. All messages, regardless if send to stdout or stderr, can be > parsed. There is no rule in this world that says you shouldn't or couldn't > do so. Aside from the stdout output in ffprobe, no stdout/stderr output is standardized in FFmpeg and thus can be changed at will (and does regularly). You can try to parse it, but there is zero warranty that it will work the next day. Regards,
On 11/09/16 18:27, Clément Bœsch wrote: > Aside from the stdout output in ffprobe, no stdout/stderr output is > standardized in FFmpeg and thus can be changed at will (and does > regularly). You can try to parse it, but there is zero warranty that it > will work the next day. > > Regards, Did you at least read the second part of my mail? Because I sure do get you don't care. It's all you, Nicolas and Hendrik have been saying here really. What I want you to do is to snap out of it and to start caring. Put the message where it belongs, meaning, put it into the documentation. ffserver is not dead just yet and you should really follow the regular coding rules until it is. And of course do users often have to accept the consequences of a changes, but they also only ever will do so when a change brings an actual gain. Nobody wants to accept a useless change. Your change, to put a message to stderr into the code, just has no gain for anyone who is using it and can only upset. Can we agree on this or am I talking to a wall? Sven
On Sun, Sep 11, 2016 at 06:52:50PM +0100, Sven C. Dack wrote: > On 11/09/16 18:27, Clément Bœsch wrote: > > Aside from the stdout output in ffprobe, no stdout/stderr output is > > standardized in FFmpeg and thus can be changed at will (and does > > regularly). You can try to parse it, but there is zero warranty that it > > will work the next day. > > > > Regards, > > Did you at least read the second part of my mail? Because I sure do get you > don't care. It's all you, Nicolas and Hendrik have been saying here really. > What I want you to do is to snap out of it and to start caring. Put the > message where it belongs, meaning, put it into the documentation. ffserver > is not dead just yet and you should really follow the regular coding rules > until it is. And of course do users often have to accept the consequences of > a changes, but they also only ever will do so when a change brings an actual > gain. Nobody wants to accept a useless change. Your change, to put a message > to stderr into the code, just has no gain for anyone who is using it and can > only upset. Can we agree on this or am I talking to a wall? I think we disagree, because no user of a working setup will ever read the documentation just to check for deprecated tools. Having the warning at runtime is the most efficient way to reach out a maximum of users as soon as possible so they have time to migrate their setup. A bit like deprecation warning in API at build time.
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit : > Did you at least read the second part of my mail? Because I sure do get you > don't care. It's all you, Nicolas and Hendrik have been saying here really. Not really. > ffserver Please stop about ffserver. This branch of the discussion is not about ffserver, it is about you not understanding 40+ years of good software design, namely the separation between normalized reliable output on stdout and human-readable diagnosis output on stderr. stderr is not for parsing. If you do not understand why, ask Ken Thompson, or really any good book on system programming. But if you are parsing the stderr output of ffmpeg, you are doing something wrong. Not ffmpeg: you. We can probably help you to fix your programs if you tell us exactly your issue, but until now you have only been vague. And accommodating wrong practices will never be a motivation in the evolution of ffmpeg. This is the second time I explain this with different words. There will be no third time. Regards,
On 11/09/16 18:57, Clément Bœsch wrote: > I think we disagree, because no user of a working setup will ever read the > documentation just to check for deprecated tools. Having the warning at > runtime is the most efficient way to reach out a maximum of users as soon > as possible so they have time to migrate their setup. A bit like > deprecation warning in API at build time. > You are trying to cater to the wrong people. There sure are people who don't read the documentation, but who are they? ... There are those who don't upgrade and consequently have no need to read NEWS or the documentation - them you don't need to care for obviously. They will read about it in the documentation when the time comes for them to upgrade. Then there are those who expect everything to stay the same only to learn the hard way of a change - them you don't need to care for and they also won't appreciate it when you do. Then there are those who don't read the output of ffserver, because of how they run it (i.e. from a script as a daemon) and who only occasionally check their logs - they either belong to the group of "hard learners" or they have read the documentation. Your point really only makes sense if you wanted to care for people who care for documentation, which means you should properly document it. People who need to migrate have nothing to migrate to - they will try to use the existing releases as long as it works for them. They may be seeing the printed message for a lot longer than you would want them to. They won't find anything good about the loss of ffserver or having to find a replacement. They won't like the message, only a few will ever be actually grateful for it, but even they will not like it or care for it after seeing it for the hundredth time. Sven
On 11/09/16 19:45, Nicolas George wrote: > Please stop about ffserver. This branch of the discussion is not about > ffserver, it is about you not understanding 40+ years of good software > design, namely the separation between normalized reliable output on stdout > and human-readable diagnosis output on stderr. > > stderr is not for parsing. If you do not understand why, ask Ken Thompson, > or really any good book on system programming. > > But if you are parsing the stderr output of ffmpeg, you are doing something > wrong. Not ffmpeg: you. We can probably help you to fix your programs if you > tell us exactly your issue, but until now you have only been vague. > > And accommodating wrong practices will never be a motivation in the > evolution of ffmpeg. > > This is the second time I explain this with different words. There will be > no third time. This isn't how a discussion works where you get to stomp your opinion down onto others and get to make it personal. But if you want it personal, I can give you personal, because if you haven't learned in 40 years that users do parse error messages then you have only proven how little you know and what an ignorant you are. Luckily are you a coward, too, and have walked out of the discussion, which seems to be the upside to your character. Was this personal enough for you? Sven
On Sun, Sep 11, 2016 at 7:52 PM, Sven C. Dack <sven.c.dack@sky.com> wrote: > On 11/09/16 18:27, Clément Bœsch wrote: >> >> Aside from the stdout output in ffprobe, no stdout/stderr output is >> standardized in FFmpeg and thus can be changed at will (and does >> regularly). You can try to parse it, but there is zero warranty that it >> will work the next day. >> >> Regards, > > > Did you at least read the second part of my mail? Because I sure do get you > don't care. It's all you, Nicolas and Hendrik have been saying here really. > What I want you to do is to snap out of it and to start caring. Put the > message where it belongs, meaning, put it into the documentation. ffserver > is not dead just yet and you should really follow the regular coding rules > until it is. And of course do users often have to accept the consequences of > a changes, but they also only ever will do so when a change brings an actual > gain. Nobody wants to accept a useless change. Your change, to put a message > to stderr into the code, just has no gain for anyone who is using it and can > only upset. Can we agree on this or am I talking to a wall? > We don't care because "caring" would severly limit the things we can change in the code. Do we have to argue everytime we want to extend a warning or error message in the future? No, we really do not want to start doing that, and thus we will also not now. There are limits to how much "stability" we can realistically provide, and warnings/errors on the console are not part of that. - Hendrik
On 11/09/16 21:41, Hendrik Leppkes wrote: > We don't care because "caring" would severly limit the things we can > change in the code. Your logic would be sound if the code hadn't been declared as deprecated. I do agree that for live code the users have to accept changes when it means there is a real gain from it, but because it has been declared as deprecated are you trying to make changes to code when you officially no longer want to make changes. You then wouldn't put a message into ffmpeg to point out that it hasn't been declared as deprecated. Although I am sure there may be a some users who could be happy about such a message, maybe some may even be worried about the news of ffserver and find such direct message useful. Yet would I not consider this to be a real gain or an acceptable change. I am guessing for once you wish to be lazy and by sticking the message into ffserver, thinking since it is going away anyway why care? But it's not actually user friendly, because anyone who is using it will now get this message each and every time they starting the server. And it's not like there aren't good places to put the announcement. Sven PS: I swear I've sent the last message only once! :)
diff --git a/configure b/configure index b11ca7f..d67d8a2 100755 --- a/configure +++ b/configure @@ -116,7 +116,7 @@ Program options: --disable-ffmpeg disable ffmpeg build --disable-ffplay disable ffplay build --disable-ffprobe disable ffprobe build - --disable-ffserver disable ffserver build + --enable-ffserver enable ffserver build Documentation options: --disable-doc do not build documentation @@ -1615,10 +1615,13 @@ LICENSE_LIST=" PROGRAM_LIST=" ffplay ffprobe - ffserver ffmpeg " +DEPRECATED_PROGRAM_LIST=" + ffserver +" + SUBSYSTEM_LIST=" dct dwt @@ -1644,6 +1647,7 @@ CONFIG_LIST=" $LICENSE_LIST $LIBRARY_LIST $PROGRAM_LIST + $DEPRECATED_PROGRAM_LIST $SUBSYSTEM_LIST fontconfig incompatible_libav_abi @@ -6492,7 +6496,7 @@ test -n "$random_seed" && echo echo "Enabled programs:" -print_enabled '' $PROGRAM_LIST | print_in_columns +print_enabled '' $PROGRAM_LIST $DEPRECATED_PROGRAM_LIST | print_in_columns echo echo "External libraries:" @@ -6682,7 +6686,7 @@ print_program_libs(){ eval echo "LIBS-${1}=${program_libs}" >> config.mak } -map 'print_program_libs $v' $PROGRAM_LIST +map 'print_program_libs $v' $PROGRAM_LIST $DEPRECATED_PROGRAM_LIST cat > $TMPH <<EOF /* Automatically generated by configure - do not modify! */