Re: [FFmpeg-devel] [TC] checkasm: use pointers for start/stop functions
On Tue, 25 Jul 2023, Lynne wrote: I think, however, the process has become rather opaque in this case. Usually, there has to be a clear writeup of the issue, with all context removed, that all parties have to agree on is presentable to the TC for guidelines. In the past, whenever developers have thrown in random comments for a TC discussion, this has been followed, and the TC has not responded, but what makes this case so special, when this was also the case? This case was admittedly very opaque. I've seen numerous cases threatening to escalate disputes to the TC. The difference here was that an actual direct mail was sent to the TC requesting to take a stance on the matter to unblock the patch. It wasn't a case of the TC deciding on its own to get involved. Now admittedly, to follow correct procedures, the TC should have announced on the ML that we are discussing this issue and trying to make a decision. Unfortunately I didn't notice that part in the description of procedures until the discussion was done (and the patch review on the ML had progressed with a new patchset that made good progress anyway), but we wanted to make it publicly known that we had been invoked and actually had had a discussion on the matter and made a decision, as was requested. // Martin ___ 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".
Re: [FFmpeg-devel] [TC] checkasm: use pointers for start/stop functions
> > I think, however, the process has become rather opaque in this case. > Usually, there has to be a clear writeup of the issue, with all context > removed, that all parties have to agree on is presentable to the TC > for guidelines. > I don't see why such a writeup is relevant, the mailing list discussions and the patch are enough. The TC isn't a debating society. Kieran ___ 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".
Re: [FFmpeg-devel] [TC] checkasm: use pointers for start/stop functions
Jul 24, 2023, 23:27 by mar...@martin.st: > On Mon, 17 Jul 2023, Rémi Denis-Courmont wrote: > >> Since you're giving zero valid reasons, I'm invoking the TC. >> > > Just for public record and visibility: > > The TC has discussed the matter at hand. Overall, the TC considered that the > approach of using an indirect call seemed tolerable given the benefits and > could be accepted if necessary. But avoiding the indirect call unless there > actually are multiple timing providers would be even better, retaining the > same low overhead as before. > > As the updated patchset seems to implement that, we consider the case closed > - and actual TC involvement wasn't needed after all here. > > // Martin Storsjö, on behalf of the FFmpeg Technical Committee > I do think TC involvement here was unnecessary - I do not object to this version of the patch, so LGTM. I do agree with the decision overall, but this is nothing that couldn't be solved with a 3 minute discussion. I think, however, the process has become rather opaque in this case. Usually, there has to be a clear writeup of the issue, with all context removed, that all parties have to agree on is presentable to the TC for guidelines. In the past, whenever developers have thrown in random comments for a TC discussion, this has been followed, and the TC has not responded, but what makes this case so special, when this was also the case? Plus, even now, I have zero idea who is on the TC - it has been three years since it was made, and although it's not meant to last for so long, I doubt there's a need for a vote as the final results would probably remain the same. But I would like to know who is still actively involved, and whether all of the people on the TC discussed this, as it's necessary to make a decision. If this was an informative guideline, rather than an actual decision where all members voted and agreed, I think this should be stated. If the TC were to actively get involved and give decisions without following proper procedures, it would do more than what the TC was meant to do - resolve issues. ___ 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".
Re: [FFmpeg-devel] [TC] checkasm: use pointers for start/stop functions
Martin Storsjo (12023-07-25): > The TC has discussed the matter at hand. The TC (and CC) has been elected for a year in July of 2020. That means your mandate is two years expired. This decision is therefore not binding. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [TC] checkasm: use pointers for start/stop functions
On Mon, 17 Jul 2023, Rémi Denis-Courmont wrote: Since you're giving zero valid reasons, I'm invoking the TC. Just for public record and visibility: The TC has discussed the matter at hand. Overall, the TC considered that the approach of using an indirect call seemed tolerable given the benefits and could be accepted if necessary. But avoiding the indirect call unless there actually are multiple timing providers would be even better, retaining the same low overhead as before. As the updated patchset seems to implement that, we consider the case closed - and actual TC involvement wasn't needed after all here. // Martin Storsjö, on behalf of the FFmpeg Technical Committee ___ 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".
