Amarok Blog

So, I’ve taken two days totally off from almost any kind of communication, I tried to relax, and now I feel a bit better. I still do think I haven’t been able to do much good beside my work on Gentoo, but I’m not ready yet to give up, even if it’s hard to continue, I will continue. At least for a while.

Unfortunately my current UPS setup is not going to fly, X-Drum in #gentoo-it informed me last night of the incompatibility between PSUs with active PFC and UPSes with stepped sinusoidal wave.. and the new PSU I bought two months ago has active PFC. The result is that I need a new UPS, of the Smart UPS series from APC, which will cost me ?420, sigh.

Talking about the topic in subject, two days ago I analysed most of the xine-lib plugins with pahole (with a patch to fix an integer overflow in the offset counter (the author wasn’t expecting structures bigger than 64KiB, but this in xine-lib is not rare), and I do have at least one good news: FFmpeg decoding of non-mpeg video streams was taking 1MB of memory for a libmpeg2 buffer that was not going to be used; I’ve now fixed this so that the structure is only allocated and initialised when needed, so decoding will take 1MB of memory less than before, on next xine-lib release.

Unfortunately, I’ve found similar mistakes in design in other structures, most of which are public, so part of the libxine ABI, and thus I can’t fix them in the 1.1 series, not unless there are good reasons and good results to achieve by breaking it. But, next week we’re going to move to Mercurial, thanks to Darren Salt and Reinhard Tartler who are helping with the migration (for who’s wondering about hosting, it will likely be on Alioth, if they accept us), so I can branch out and fix the stuff.. and then merge back in either 1.1 or 1.2 as we feel needed.

One of the structures I surely will be refactoring is the video overlay structure.. that has a size over 4MiB as it is, which explains why the function to initialise video overlay consumes 5MiB of memory right after xine initialisation, even when playing a sound file. By instancing the structures only when really needed, and making sure that there aren’t holes around, it should be possible to reduce drastically the memory used up by xine.

Another thing in my TODO list is, as I said already, rewriting the plugins cache code. I will also try to provide a simple way to regenerate this cache globally, so that for instance it can be installed directly by the ebuild, without asking users to regenerate the cache by theirselves, and sharing it in memory (through mmap) between users too.

To help this, I’ll also see to change the way the plugins are handled, by using where possible inline arrays for the names and description of the plugins, rather than pointers, allowing to share the structures in memory, where this does not waste too many bytes.

Anyway, I still need to relax a bit more because I can’t really rest lately, and I do need some rest if I am to carry on.

Edit: thanks to Mike Arthur for letting me remember I got the phrase wrong, the permalink will have to stay wrong to avoid confusion though :/

So today’s news are that a bunch of people who never seemed to care about ALSA (sorry Tony but iirc you said that yourself) now will be the new ALSA maintainers. And their first action is to flush down the toilet the months of work I’ve put in making sure that the official alsa-driver package works.

Okay, well, their responsibility.. but again, what about those people who need to use alsa-driver? While Josh (nightmorph) agrees that it’s more than 2.4, Daniel seems to care about it just for 2.4 and those few extra drivers on it. Tell you what: neither my boxes can run in-kernel ALSA, as they both die with it.

And has any of them tried to contact me? I told to them already that the ALSA maintainer’s guide is incomplete, were they able to fill the gaps that I haven’t been able to update before leaving without asking? Maybe.

But with all due respect, Steve wasn’t able to find time to proxy-commit the ebuilds I already prepared for ALSA, Petteri did it.

Do they know about the six bugs that I’ve opened on the ALSA bugs tracker that are patched in Gentoo?

For the way it has been handled, I do think Daniel is just trying to get revenge for my handling of ALSA, sorry Daniel, I respect you, but you’re dead set on the wrong way to see the issue this time. And I’m pretty sure that it will create problems.

I don’t think I handled ALSA all that bad, I didn’t get any help by any other developer, and Daniel tried to push me off track once or twice, but there weren’t many users complaining about ALSA not working… while we all know what happened on the 1.0.8 to 1.0.9 update (or do we? rather, do they? I was there, not sure where they were on that one); genstef failed already once trying to take over ALSA from me, by the way, and if it wasn’t for my proxied commit, ALSA 1.0.14_rc3 wouldn’t have been in the tree most likely (released 6 March, my ebuild was ready on 7th, Petteri committed it at 17 March after leaving some time to see if someone else was going to pick it up).

Anyway, with the future in hands of those devs, I think I won’t restrain myself from saying “I told you so” when, in a couple of months, you’ll hear users complaining about their VIA82xx card or their HDA card not working. Bets are open on when the first signs of something broken will appear.

Oh, someone in there is going to actually take care of what I left incomplete (ld10k1 init script), or is that not cool enough?

Today I was finally able to talk with Vir (Matthias Kretz, the Phonon guy), and I got a partially good news, but also a pretty bad news.

The good thing is that there will be a notification daemon in KDE4, that will use Phonon, so that not every application that requires notification will have to load libxine (and all its damned plugins); it might be loaded on the fly on a file dialog to preview a multimedia file though, which means it’s still going to be used by more than just a couple of applications at a time.

So the result is that we are in the need to branch xine-lib to make more consistent changes to the codebase for a 1.2 series, like for instance a shared cache for the plugins, created – if at all possible – during make install phase, as well as configuration options caching. It’s a massive amount of work that has to go in that direction, so we can make more data in the plugins constant, reducing the chances of having to make the RSS pages dirty, so reducing the overall size of xine-lib’s memory occupation.

Other changes includes the ability to choose the demuxer through a shared mime type, rather than by extension, which would allow not to have to load all the demuxers one by one when we’re passing through them, and a way for the plugin to tell the library if it supports ways to check what it can demux other than by content (some plugins fall back to a by-content detection when they don’t support an extension decoding); plus there is the always-improvable support for seeking, right now there is only one choice: an input plugin can seek or cannot, simple as that, while there can be difference grades of seeking: no seeking at all (sequential), slow seeking (you can seek, but you shouldn’t just jump around to find what the format is, an example of this is HTTP streaming), usual seeking (which is what most plugins already implement), and time seeking (MMS and RTSP support this).

RTSP support is also quite lacking, and it could certainly get improved by using libnemesi (Luca knows I tried already but as it is the structure of xine is not good enough); and another external library we might as well use is libavformat from FFmpeg: right now we only support libavcodec and, to some extents, libpostproc from FFmpeg project, while we could easily make use of libavformat as an extra demuxer plugin, as that can certainly support a lot of formats without us needing to take care of them one by one.

Unfortunately, I don’t think we’ll be able to provide much of this with a 1.2 series right away, especially since we don’t have many developers around at the moment, but that can be hoped.

Now, to return on the title of my blog, I’ve decided to play a bit with pahole, a nice software coming from Arnaldo Carvalho de Melo, a kernel developer, that is able to analyse the dwarf data of binaries (them being final executeables, libraries or kernels) to identify the structures used internally, and their content, to find their size and the eventual padding holes that would allow to reduce their size.

Well, a simple run of it, shown that there is at least one structure video_overlay_object_t (which is also used in video_ovelray_event_t) that takes more than 80KB of space. I’m not sure how many of these structures are loaded, but even a single one is a lot of space used, and I’m quite sure most of it is wasted; as far as I can see, it is used for the overlaid buttons in DVD menus (and other kind of menus I suppose, although I don’t think we currently support Matroska’s menus, although I’m not sure of it); even if that is the case, I don’t really see often DVD menus with 32 buttons, and as every button take more than 2KB, it should have probably be improved by using a button list rather than a static array, allocating the buttons only when effectively needed.

As I said there is a lot of work to do, especially when it comes to memory, but hopefully as soon as we have a new DVCS the work might become easier. Of course switching to a distributed mode will require some adjustment time, as we all need to learn Mercurial (well beside Darren that is), and there will be a lot to do to let others involved, but for instance then the VDR patches from Reinhard Nissl would just become a different branch of xine-lib, that could easily be merged from time to time (today I merged two more patches from him, and I’m sure more will come in the future).

I suppose right now the main question is: where will we host the sources? I suppose the best thing would be some hosting provider on this side of the Atlantic to avoid USA patents, but it’s still something we haven’t taken a sure decision, one idea was to ask on Alioth but it’s all up to be seen.

If the switch goes well, I could also see us moving away from SF.net’s tracker system, that is pretty much unusable, but there isn’t much choice about it, I don’t intend using Mantis again in my life (I used it for NoX-Wizard, do you remember Fabrizio?); Scarab looks interesting, but I’m not sure where we could find an hosting provider with JSP support for no price (or a cheap one).

Oh well, time to go to sleep soon now. If you’re interested in pahole, you can find an ebuild for it in my overlay (I know, gitarella is having trouble, I’m afraid that the Ruby update screwed up both gitarella and ServoFlame, so my services are down until I find time (and will) to fix them.

Okay, tonight just a quick post. First of all, totally unrelated with the title (okay still distributed stuff, but not a nightware), GIT was discarded as option for xine-lib’s future Version Control System, we instead decided to go with Mercurial because of its availability on a wider range of platforms (GIT is not officially supported on Solaris at least, and Cogito does not work at 100% on FreeBSD); I also cleared up my previous doubt about it, both speed and features of the two softwares seems to be at the same level, so portability has been the breaking requirement. Darren converted the CVS already, creating a bunch of repository (due to branching), and it also got support for the user ID to author name translation (which means you’ll see the commit coming from Diego ‘Flameeyes’ Pettenò rather than from an anonymous dgp85).

With reference to my distributed nightmare, instead, I want to thank Mike (vapier) a TON, his last version of nfs-utils (1.0.12-r2) finally fixes my problem with FreeBSD clients, so I upgraded Farragut (breaking ServoFlame in the mean time I’m afraid) and now I’m putting Prakesh back into shape so I can start playing with Tomcat again.

So I don’t have to get crazy with Coda, nor I have to buy a new box right now; I’ll eventually do it, as I start to feel this box is slow, but for now it’s fine as it is without more money to go away; this is good because I can then buy the new Yu-Gi-Oh game as soon as it’s released

Anyway, tomorrow it’s working day again, so I should be sleeping, the DST switch threw me off, and I was awake all last night with the jigsaw my sister gave me… 121×80, 3000 pieces.

So, today almost no xine work, actually almost no work on Open Source at all; I had to relax a bit myself, and I had to continue testing stuff for my job before the contract expires (at the end of the month), but I found time to write to xine-devel again, asking to change version control system, because CVS is driving me nuts.

Why do I think xine needs a better version control system? Well, it’s actually easy to say; read my two previous posts, and you a see that there are a lot of details that I think should be fleshed out and fixed, especially in foresee of xine being default Phonon’s engine.

Some of these, like the memory management thing I thought of, aren’t changes that you’d expect in a stable branch, or even on a «future development» branch, as it can be risky, needs a lot of changes, and is not, in its first stages, targeted to anyone but the developer doing the work; one can develop locally, but that means he loses ability to check its paces without losing history, and also is a mess to merge back into the main branches, as you usually end up doing one big commit with everything.

Branching with CVS sucks, or rather it’s the merging that sucks a lot, something I don’t really want to try if I can avoid it. Subversion improves a bit, but I still think it’s flaky, while the whole distributed VCS series that we get nowadays (GIT and Mercurial first), uses branches as main unit of development, rather than repositories. This is quite cool for this kind of tasks.

In addition to this, non-atomic commits are problematic, and the current workflow is a total mess, as the only really active developers in xine lately have been me and Darren Salt (gxine’s author), with Claudio Ciccani working on xine-plugin. Miguel’s commits result to be slightly less than Darren’s because he checked in a few FFmpeg’s bumps, which caused the commit amount to jump up (non-atomic commits, once again). What we need is an adrenaline injection, simplifying the contribution of patches from users, hoping to find new developers or the project will wither.

Now we’ll see what will be the outcome this time around; sincerely I’m not going to accept the answer I got last time about not being yet the time to change SCM, said by the admins, whom are not committing for months now (I didn’t find even a single commit from Mike on the last six months).

On the other hand, to play locally with importing xine into GIT to see the results, I’ve written a nice script that, when ran on a checkout of a CVS repository on SourceForge.net, will give you the authors file suitable for git-cvsimport use. It page-scrapes SourceForge’s users page to get the real name there given (which might not be perfect for users who didn’t update their name after sf switched to UTF-8), and uses the user (at) users.sourceforge.net mail address, so you might want to change it a bit for instance if you know some users will prefer advertising another address, but it should cover well for those developers you can’t contact anymore (disappeared or passed away even). The page-scraping is done through wget and awk (the awk script is inlined in the sh one), and the script is actually one single command pipe (with a loop and a subshell, okay) to the shell, if written properly it can easily be a oneliner.

It might be useful if someone else is thinking about changing from SF.net’s CVS to GIT?

I’m continuing the work to make xine build (and hopefully work) on OS X, that I already started talking about a few days ago.

Again, the main problem of getting xine to build on OS X is to make the build system aware of it; I started the work on this some time ago by letting the configure understand the difference between PowerPC and Darwin, but that was just the first step of a long journey.

After the other night, though, there has been a bit of a stall, as the fixes I committed, cleaning up the configure.ac, ended up using some features coming from autoconf 2.60, so Bastien Nocera (Totem’s author) reported some problems when building with 2.59. As nobody but him seems to have noticed a difference, and as autoconf is just a tool for developers rather than for the users, I’ve updated the pre-requisite declaration on configure.ac and I’m waiting to hear from the “council” of the xine developers to see what they think about it. I suppose that 2.60 macros will be welcome to be used on the long run anyway.

Now, I have to say that the autoconf and automake code I found when I first started fixing xine, before being a developer and just helping out with Gentoo, was really messy, and it still is for the most part, at least for the code that hasn’t been updated yet.
Today I even found an install and uninstall rule for the default headers, that were being rewritten just to change the destination directory (while it would have been enough to just change the name of the headers’ group, and then replaced its foodir variable).

So from this side, overhauling the configure code is a good idea; with the changes I’ve been doing, the time requested to run the configure should be way shortened; unfortunately there are other problems like pkg-config checks that currently miss the AC_MSG_RESULT and a few tests that should be cached.

Adding a test for a GNU assembler wasn’t easy either, as I had to copy for a GNU ld from libtool, and adapt it.. but then Apple’s assembler reports itself as GNU as (1.38), which doesn’t support the syntax I needed, so I had to adapt the macro to consider Apple’s assembler a non-GNU one. Now I could make the Win32 codecs disabled by default when building on OS X with non-GNU assembler (if you were to use GNU binutils and thus GNU assembler, it would build it, probably, not sure if it works though).

This solved the problem I left the other day, but of course there were more to come, or Murphy wouldn’t be so famous. So there I was again to hack on the configure, as the planar post plugin required a byte-alignment instruction (.balign) not available on the Apple as; I then worked differently the code for the ASMALIGN macro from FFmpeg to have it available on the entire source, allowing me to use it where needed, so that the planar plugin built (thanks exg for the help here).

And was this the end? No of course, now there is the greedy deinterlacer, requiring more registers than needed, that intends not to compile on OS X, not even with -fomit-frame-pointer… the code probably has to be rewritten, maybe the big asm chunk split in simpler parts, but I’m not a big ASM expert, so I’m not sure how I’ll do that.

Anyway, I haven’t given up yet, although the road is still long… just never ask me to do this for Windows !

The problem instead is that tonight, talking with eean and leinir on #amarok, I understood there are a lot of pitfalls in the current xine code, that will be evident as soon as Phono is going to be used for system sounds in KDE: the plugin cache does not work, other then being a human readable text file (which makes parsing slow, compared to a binary cache), and crashing on some invalid data (there’s a bug open for that), the fact that configuration entries are never cached makes it pointless for those plugins having a preload flag enabled. Also, the memory waste I talked about makes even more sense now, especially because by using multiple instances, using mmap to read the files improves the situation a lot, as they can share the same memory area for the same system sounds, even between users, and if I can make the mmap being the only source of data for the library, rather than having to copy it around over and over, it will not add extra memory footprint on them.

I think I’ll have really to study more about memory management, if anybody has a suggestion, it’s very welcome.
And seeing the amount of work that I’ll probably have to pour into xine in the next months thanks to KDE 4, donations are even more welcome, especially when they come with a sample of a file not playing correctly to be fixed… better now than when people cries because they can’t use their sounds for the events. (I don’t like saying it this way, but I admit I was a bit upset when an user seemed to demand that xine resumed playing very old Ogg files, saying that the fact the format is crappy does not make the problem any less real… sure it’s a real problem, but I’m already doing quite bit for xine, and I’m almost alone.. and I know I’ll burn out when people will start demanding improvement in xine just because it’s being used by KDE 4!)

[Would it be worth asking again on xine-devel to give me a better SCM to work with? CVS is really giving me creeps, and making it almost impossible to start working on a 1.2 series… or even a separate branch for a new feature, like the memory thing]

First of all thanks to Alex for showing me that is not just my fool idea that there is something wrong in what is currently considered QA in Gentoo.

Then, before entering in the topic of this entry, I want to say that I’m sorry that today Farragut was down for two hours straight… a temporary construction fell over the power?lines on a construction yard (no, luckily not in any house I have to visit myself, I wouldn’t trust them if they can’t even get a temporary storage that does not fall over at the first windy day), and the power company doesn’t seem to think of this area like a priority. This makes it 7 hours and a half of blackout this month.

Now, to get on topic, this is the second part of my series about the reason why I left Gentoo.. it’s not exactly proper, I could have stand this easily, it’s just something that I do think it’s a mistake for Gentoo, and that should be considered as one thing that has to be fixed.

I think this is probably what Daniel missed entirely when he returned. Being a Gentoo developer is not a right, nor a privilege, it’s something else.

You can easily understand why it’s not a right, or rather how it’s not a right: you need to pass a test and the recruitment process to be able to join the Gentoo Developers pool, this is right because of course nobody is entitled to be a developer just because he wants. One has to prove not to be a burden to the developers, to know what he’s doing and to be able to actually work on the tree. It allows to shoo away time wastes and people who are not going to stick around, and just seems to come for.. not sure for what, but you can continue reading what I think the other problem is to complete this view.

Now, about the privilege, I want to let everybody know that there is nothing good at being a developer most of the times. What you get, is a nice email address, which beside having a good impression on you resumé (or on your Curriculum Vitæ if you live on the right side of the pond?) can help you to get some hostile upstream developers more friendly, but this is far from being an advantage, trust me; you get access to the Gentoo Infra, but what for?

All you have, is access to actually do more work, to check and close bugs, to commit stuff, to work on projects, to take care of ebuilds, packages, whatever. You get to follow policies, you get to be blamed if stuff doesn’t work. What you get, is only responsibility.

If you have to work with an hostile upstream for which you need a Gentoo mail address, you are not really looking for a privilege or an advantage, but just for masochism to work on something even more complicated.

The reason why I decided to become a developer, was to give back something; I was (and am) an avid Free Software user, and I wanted to contribute. I was looking for no advantage, I knew I was expecting work and responsibilities, and with this in mind, I joined Gentoo.

But now, why should I be considering that I would get fired if I ask for a specific condition to be met by my employer? I actually already make sure that some conditions stands when I’m working on something, might it be I don’t have to work on Windows, or it might even be that I don’t want to work in team with someone.

When I asked Bryan to take care of enacting geoman’s brag about retiring, I was posing a condition on my work. It wasn’t met, I left; I see no point in calling this a «blackmail», I think Steev probably labelled it most correctly as «ultimatum», but I don’t see it with such strong negative connotations. Considering it’s a volunteer work, that has nothing good to offer me, and for which I only had to offer my time, I find deciding whether to continue on it or not is my prerogative; if that depends on a particular issue, then let it be. If Bryan decided that acting on geoman’s retirement «plan» was okay, I would have just continued doing my job.

Now of course there are projects for which being a developer is a privilege, because you can access secret repositories, secret sources, secret documentation or whatever else, or because you get paid, or not sure for what else. Gentoo is not like this, not anymore. This is what Daniel missed, when he was in charge, being a developer was a privilege, now it is not, so there’s no much point on trying to deny anyone from being a developer to hurt them, the only point is to keep poisonous people from ruining the experience of other developers.

And before I get misinterpreted, I’m not saying that users weren’t thankful, I actually thank everybody who said thanks to me, o who sent me a gift, they were appreciated, and really helped me carrying on with some things I didn’t like So it’s not totally bad, it’s just that it’s not good by definition, being good is an extra, and that works out only if you actually do your share of work for the community. Thank you guys!

? Before I’m told I’m insulting the Americans, as long as North is up, we in Europe are on the right side, while USA is on the left side. It’s a joke, or a pun as you prefer, if you want I can make you a scheme, hm?

As a few people already asked me directly which were the so-called «real reasons» for my leaving. As I said, the straw that broke the camel’s back was the one I already expressed in my goodbye post, and it’s not concealing a different reason, for that. Still, there are plenty of reasons that got me tired, and that predisposed me for leaving so quickly when I really grew tired.

I given a brief interview to ABC Linuxu (the article is available in Czech, I do hope it was translated correctly, Jakub seems to think so, so I trust him on this), but of course I cannot point everybody just to that. I’ll then see to dedicate a few blog entries on this topic, now that my cold seems to have wore off and I’m concentrating on getting my job confirmed after this month.

So let’s start with one of my main concerns about the status of Gentoo when I left it: the Quality Assurance idea, and policy being «enacted».

First of all, I want to point out that I’m not targeting Stephen alone on this; while I cannot say I really do like him, I still respect him to an extent, and he was a mentor so I still owe him something. The problem here is more embedded in the whole Gentoo developers pool, as also Mark (who I also respect, sometimes more than Stephen, if that says something) was going on the totally wrong direction, in my opinion.

So, let’s start to see what I mean. All the past Quality Assurance efforts, that fell into the QA project and that were labeled QA, were focused on enforcing a code correctness on ebuilds, eclasses, profiles, practises, processes, and so on. I’m not saying this is not a good idea, but I do think that this is not what the Quality Assurance team should be focusing on; this should be more like a «code police» project and team, limited, which could make sure that of all the possible variants way to do something, the most correct formal one is chosen every time; calling it «code police» can be harsh, but calling this Quality Assurance is not only misleading, but also diverges forces from the actual need for a Quality Assurance team and process.

So, what do I think the QA team should take care of? First of all, it should focus on the Gentoo user side, rather than on the internal development: Quality is an attribute of the final product, not of the internal state of the ebuilds. Nobody will notice, nobody will care, if the ebuilds are totally correct on the code side, but they don’t work well together, and trust me, I know quite a few examples of ebuilds that needed to be better handled in the past, and in the current situation too.

The first example are those ebuilds that are marked stable for an architecture (mostly x86) but does not work at all, not even build sometimes, because newer version of their dependencies dropped something, or one of the old dependencies’ dependency is no more present and the ebuild should have also depended on that one. You don’t think this is so common? I can tell you that CJK team had quite a bit of problems with this kind of ebuilds, especially because of modular Xorg, and ebuilds like jfbterm that were missing dependencies on xorg-x11 or alternatives, as they didn’t use it directly.

One thing that helped a lot on this for CJK team was the work of Patrick Lauer with the tinderbox. The bugs he filed about ebuilds not completing their build phase often involved app-i18n packages, and that allowed me to find some fonts packages that needed to be revbumped, or marked stable, and jfbterm itself, that was totally broken on stable.

Most of the time, the secret of a good Quality Assurance, as experienced by users, is a proper communication between teams; sometimes this needs to either wake up a team, or to take its place, or to find replacement for it. While Donnie and Josh did a hell of a good job to handle the Modular Xorg migration, and we are all happy to see how smooth it ended up, some of the packages needing a new stable after the modular packages gone stable too were missing because, well, the teams weren’t there at all. I joined CJK team afterward, or I would have taken care of that myself, but before that there was just a mess, because a team wasn’t responsive, nor existing.

A similar problem happens when a new package is added that breaks API, rather than ABI. Thanks mainly to Alexis, FLAC bump to 1.1.3 will be pretty much painless for Gentoo users: it was introduced in package.mask by me, and we both checked every package depending on FLAC. Unfortunately not every bump is handled this way because, well, there is a lot of work to do for handling it this way, and leads to higher delays into getting the package available for users to test, increasing in turn the maintenance burden for the package in overall. Many developers prefers handling this by using an overlay, to a similar result, although I do prefer handling everything in main tree when possible, or should I say «did»? I’m no more a developer so I don’t have any voice in this anymore.

There are also other problems, that are already labelled as QA problems, like the libraries missing soname or needed entries (this latter in turn is a source of --as-needed incompatible software, if you wondered why I always interested in that detail), but most of these misses a clear documentation, and they are not given any priority over the correctness of ebuild files for corner-cases (like ROOT != /, that strictly speaking is only needed for a subset of the packages for catalyst).

So my point on this is that the name of QA is being totally misinterpreted by almost the whole developers pool (or at least so appears as very few people spoke against the current situation), and what we’re in front of is a simple case of excessive perfectionism. Quoting Voltaire:

Le mieux est l’ennemi du bien. The best is the enemy of the good.

(I regret not having studied French in more than eight years now…)