| Message ID | 20220817214932.42351-1-george@nsup.org |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,1/2] doc/plans: add a file to list approved projects | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
I am very strongly against this. You keep trying to preemptively shield your code from criticism that you're unable to deal with, rather than actually build consensus. Stop that, it will lead to nothing good for you or the project. You also keep insinuating that I'm "blocking" your precious avwriter. I am not blocking anything. You asked for opinions on it, I gave you my personal opinion. I even gave suggestions on how to proceed with it. Rather than engage with them, you started ranting at me, as you always do when someone disagrees with you, followed by melodramatic theatrics. You're going to have a bad time around here until you learn how to deal with disagreements constructively.
n Wed, 17 Aug 2022, at 23:49, Nicolas George wrote: > doc/plans.md | 6 ++++++ > 1 file changed, 6 insertions(+) Those plans files become outdated very quickly and are often not maintained. Or they become infinite unicorn-wishlist things. Or they become a blocking task for the project. I have NO opinion on AVWriter, but just show the API and documentation before implementing it. Once people agree on the API need and form, just implement it, I don't see the need for a plans.md file for that.
Jean-Baptiste Kempf (12022-08-18): > Those plans files become outdated very quickly and are often not maintained. > Or they become infinite unicorn-wishlist things. > Or they become a blocking task for the project. Or I might be hit by a bus. Or I might decide to try heroin and overdose because it was cut with fentanyl. Or… If we always focus on the worst-case scenario, we never go forward. Worst case scenario here? It becomes blocking, we discuss to remove it, wasted a little time. Less worst case scenario: it becomes an unicorn-wishlist, somebody finds something doable in it and starts contributing to the project. Anyway… > I have NO opinion on AVWriter, but just show the API and documentation before implementing it. > Once people agree on the API need and form, just implement it, I don't see the need for a plans.md file for that. Hum, I like that idea. For AVWriter, much of the API itself is macros and inline functions, but it is a minor issue that I can work around. “Once people agree” means applying it; I hope nobody will bikeshed the idea of pushing a .h file with no implementation I insist that I am not doing this to “preemptively shield [my] code from criticism”, like Anton disingenuously said. If that was the case, I would not have written “The resulting patches will be subject to technical review like any other patches”. What I am trying to do is to find a way to discuss broad strokes before investing time in details, because without it the project is condemned to immobility because of naysayers. It is not specific to AVWriter, it is not specific to me. If we had that procedure at the time the new channel layout API was implemented, then we could have discussed it to take into account the needs of users, filters, advanced formats and devices and now have a great channel layout API. Instead, we had to salvage one that was not designed with these considerations in mind, but because it was a series of 279 patches, nobody dared send it back for complete redesign as we should have. I find this borderline dishonest. Depending on the responses to this mail, I will send a patch to add avwriter.h and doc/avwriter.md and start the actual discussion. Regards,
On Fri, 19 Aug 2022, at 18:01, Nicolas George wrote: > Or I might be hit by a bus. Or I might decide to try heroin and overdose > because it was cut with fentanyl. Or… If we always focus on the Exactly. This is called the bus-factor and is important in all volunteers open source communities. Which is why the norm is "show us the code" and not wait for future things. Because as we are volunteers working when we can, shit happens in real life, so you cannot block a project with future plans until they are done. Because maybe it's a 6months time or a 2 years time, or never. And then you never ship your software. For the same reason, something "ready to merge, not optimal but better than the current state" is Always better than "I'll do an optimal solution in 3 years". Especially since the first solution does not block the latter one. Therefore, I don't think those plans documents are useful: "show us the code!".
Jean-Baptiste Kempf (12022-08-19): > Exactly. This is called the bus-factor and is important in all > volunteers open source communities. > > Which is why the norm is "show us the code" and not wait for future > things. > > Because as we are volunteers working when we can, shit happens in real > life, so you cannot block a project with future plans until they are > done. Because maybe it's a 6months time or a 2 years time, or never. > And then you never ship your software. > For the same reason, something "ready to merge, not optimal but better > than the current state" is Always better than "I'll do an optimal > solution in 3 years". Especially since the first solution does not > block the latter one. I do not agree with this absolutist statement. There is a balance to find between quick-and-dirty solutions that make further enhancements harder and vague plans on the comet. Anyway, this does not apply to AVWriter since the only things it is blocking are my own projects. Also, AVWriter is in greatest part done. > Therefore, I don't think those plans documents are useful: "show us > the code!". Try this with your plumber: “Show me my shower fixed and I'll pay you if I'm satisfied.” It does not work that way, you have to sign a sales quote before the plumber gets to work. This is the kind of mechanism I want to find for FFmpeg. I have asked you to clarify your previous suggestion: Are you suggesting that I propose the headers and documentation for AVWriter, that we discuss it and hopefully push it before investing more time in the implementation? Please answer. Regards,
On Mon, 22 Aug 2022, at 14:43, Nicolas George wrote: >> Therefore, I don't think those plans documents are useful: "show us >> the code!". > > Try this with your plumber: “Show me my shower fixed and I'll pay you if > I'm satisfied.” It does not work that way, you have to sign a sales This is a contract, with paid money and clear objectives. > quote before the plumber gets to work. This is the kind of mechanism I > want to find for FFmpeg. FFmpeg is a volunteer open source project, not a contracting or plumbing initiative. If the SoW is not done, the money is not paid. This does not work for open source communities. > Are you suggesting that I propose the headers and documentation for > AVWriter, that we discuss it and hopefully push it before investing more > time in the implementation? You provide a full header and documentation, and then get it discussed. When there is a consensus for approval of the headers, then, you can code the core of it that matches the headers. That avoids the "I spent time for nothing" issue.
Jean-Baptiste Kempf (12022-08-22): > This is a contract, with paid money and clear objectives. > FFmpeg is a volunteer open source project, not a contracting or plumbing initiative. > If the SoW is not done, the money is not paid. This does not work for open source communities. I was not asking money from the project, so… you just did not understand the simile. Too bad for you. > You provide a full header and documentation, and then get it discussed. > When there is a consensus for approval of the headers, then, you can code the core of it that matches the headers. > That avoids the "I spent time for nothing" issue. I will try that. And I will count you as support if naysayers start whining “we don't apply headers and documentation without the code”. Regards,
diff --git a/doc/plans.md b/doc/plans.md new file mode 100644 index 0000000000..0d7336e8b4 --- /dev/null +++ b/doc/plans.md @@ -0,0 +1,6 @@ +# Plans for future developments + +Projects listed below have been approved by the FFmpeg developers community, +and their author(s) can invest time and effort implementing them. The +resulting patches will be subject to technical review like any other +patches, but they can no longer be rejected on principle.
This file makes it easier to engage in ambitious and/or long-term projects for enhancing FFmpeg by removing earlier the uncertainty of acceptance on principle. Signed-off-by: Nicolas George <george@nsup.org> --- doc/plans.md | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 doc/plans.md Reference to discussion: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300193.html