On Thu, Jun 13, 2024 at 3:28 PM Jacob Champion <jacob.champ...@enterprisedb.com> wrote: > (that's not the proposal and I know/think you know that but having my > original email twisted into that is making me feel a bit crispy)
I definitely did not mean to imply that. I took your original email as a goal, rather than a proposal or plan. My statement was strictly intended as a hypothetical because I didn't think any plan had been proposed - I only meant to say that *if* the plan were to do X, that would be a hard sell for me. > I do not want to migrate, and I have stated so multiple times, which > is why I have not proposed a migration plan. Other committers have > already expressed resistance to the idea that we would rewrite the > Perl stuff. I think they're right. I think we should not. I think we > should accept the cost of both Perl and something else for the > near-to-medium future, as long as the "something else" gives us value > offsetting the additional cost. I agree. It's not terribly pretty, IMHO, but it's hard to see doing things any other way. > For me personally, the problem is the opposite. I have done _so much_ > initial development by myself that there's no way it could ever be > reviewed and accepted. But I had to do that to get meaningful > development done in my style of work, which is focused on security and > testability and verifiable implementation. I admire this attitude. I think a lot of people who go off and do a ton of initial work outside core show up and are like "ok, now take all of my code." As you say, that's not realistic. One caveat here, perhaps, is that the focus of the work you've done up until now and the things that I and other community members may want as a condition of merging stuff may be somewhat distinct. You will have naturally been focused on your goals rather than other people's goals, or so I assume. > I am trying to carve off pieces of that and say "hey, does this look > nice to anyone else?" That will take time, probably over multiple > different threads. This makes sense, but I would be a bit wary of splitting it up over too many different threads. It may well make sense to split it up, but it will probably be easier to review if the core work to enable this is one patch set on one thread where someone can read just that one thread and understand the situation, rather than many threads where you have to read them all. > Because of how many moving parts and competing interests and personal > disagreements there are, I am firmly in the camp of "try something > that many people think *might* work better, that can be undone if it > sucks, and iterate on it." I want to build community momentum, because > I think that's a pretty effective way to change the cultural norms > that you're saying you're frustrated with. That doesn't mean I want to > do this without a plan; it just means that the plan can involve saying > "this is not working and we can undo it" which makes the uncertainty > easier to take. As a community, we're really bad at this. Once something gets committed, getting a consensus to revert it is really hard, especially if a major release has happened meanwhile, but most of the time even if it hasn't. It might be a little easier in this case, since after all it's not a directly user-visible feature. But historically what happens if somebody says "hey, there are six unfixed problems with this feature!" is that everybody says "well, you're free to fix the problems if you want, but you're not allowed to revert the feature." And that is *exactly* how we end up with stuff like the current TAP test framework: ripping that out would mean removing all the TAP tests that depend on it, and that wouldn't have achieved consensus two months after the feature went in, let alone today. Now, it has been suggested to me by at least one other person involved with the project that we need to be more open to the kind of thing that you propose here: add experimental things and take them out if it doesn't work out. I can definitely understand that this might be a culturally better approach than what we currently do. So maybe that's the way forward, but it is hard (at least for me) to get past the fear of being the one left holding the bag, and I suspect that other committers have similar fears. What exactly we should do about that, I'm not sure. -- Robert Haas EDB: http://www.enterprisedb.com
