Hi Niklas On Thu, Apr 02, 2026 at 06:58:48PM +0200, Niklas Haas via ffmpeg-devel wrote: > Hi all, > > I started a vote about the best way to switch FFmpeg's internal copy of > checkasm over to upstream libcheckasm. If you are a member of the GA, you > should have received a vote link. If not, please contact me. > > I have tentatively set the end date to April 8th, which I believe gives > enough time to read the summary and come to a conclusion. If you need more > time to decide, please reply to this e-mail. > > For context, see the discussion at > https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22546
As said elsewhere, if there is to be a vote, it should be done properly. A vote should be announced before it starts, so people have time to discuss the question and suggest options. Anton and Thilo have both done such pre-vote announcements in the past. More generally, voting should be a last resort after discussion has failed to reach consensus. If discussion has already brought us close to consensus, then starting a vote risks creating unnecessary conflict rather than resolving a real disagreement. Specifically, I think this vote is missing at least one important option: 1. one flat check-in per upstream commit no merge commits, full author attribution, and straightforward use for users and developers For completeness, this could also be an option, though I do not insist on it if there is concern about having too many choices: 2. further discussion / do not merge checkasm at this time; keep using the current FFmpeg checkasm code for now Also, the option that corresponds most closely to the current PR should be identified explicitly as such. My impression is that option B is closest to the current consensus, in case someone wants to vote for that. But I can live with a range of solutions, provided that the result is not submodules. About submodules: Multiple people, including myself, have objected to them. This is not just a checkasm integration detail. Choosing submodules would be a broader structural decision affecting FFmpeg as a whole, and voters should understand that clearly. Among other things: * submodules complicate workflows such as bisection * submodules create extra friction for users and developers * submodules are not a good fit for a scalable development model of the kind FFmpeg may want in the future * as release manager, I will need to replace them one way or another in release branches this would add all the mess from submodules in git master and another solution in release branches. So I think the consequences of submodules should be presented very clearly if that option remains on the ballot. thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
