Entries tagged 'postgresql'

Today was the first day of the 21st Southern California Linux Expo, also known as SCALE 21x. I gave a talk at way back at SCALE 4x and hadn’t made it back since then.

I attended a couple of talks on the UbuCon track at the beginning of the day. They weren’t technical talks, but focused on how the Ubuntu community operates and how Canonical relates to that. It sounds like Canonical has opened itself up more to the community by adopting Matrix as both their internal communications tool as well as what the community uses, which I think is very important for encouraging the developers in a commercial open source environment to engage with the community. This was an issue for us back in the MySQL days, too.

(There was also a comment about “neck beards” being annoying about not adopting newer communication tools and wanting everyone to stick with IRC, I think coming from someone involved with openSUSE, which I thought was kind of funny.)

After that, I popped over to the beginning of the Kwaai Personal AI Summit because Doc Searls was giving a (brief) talk and I thought I would see if there was anything to this AI thing that I’ve been hearing about. The room had a lot of old dude energy that just wasn’t sitting right with me, so I ended up bailing after Doc’s talk.

Since I left that earlier than I had planned, I ended up wandering into a PostgreSQL talk on how “wait events” can be used for troubleshooting performance, and I had a déjà vu moment because only yesterday I had run across the old Worklog for MySQL’s PERFORMANCE_SCHEMA which blames credits me for suggesting that’s what the name of the schema should be. It was yet another random “plate of shrimp” moment that has been happening with frequency as of late.

Then I attended a workshop from the Kubernetes Community Day track on using Argo CD to put the OpenGitOps principles into practice. While I have been using Docker for a while, I haven’t really played around with Kubernetes or other container automation tools, so I figured this might be a good way to start learning more. Unfortunately, the hands-on workshop part of the session didn’t actually work due to some problem with the training environment from the sponsoring company, which kind of helped reinforce my instinct that a lot of these tools still have a lot of sharp edges. The concept sounds great, though.

Finally, I popped back over to the PostgreSQL track for their (apparently popular) “Ask Me Anything” session with some of the prominent community members and core developers that were in attendance. I was reminded today that the PostgreSQL project doesn’t have a bug tracker aside from their mailing list archive. I remembered writing about this before, and it turns out that was in 2008. (No shade intended that they don’t have one, it seems to be working out okay.)

That was the day. I really don’t want to seem like I am passing any judgement on anything because I know that putting on an event like this is tremendously difficult, and while there is an impressive line-up of sponsors this is clearly a community-driven and focused event. I was disappointed by how old, white, and male the crowd seemed to be (fully acknowledging that’s my demographic), and I’ll be interested to see if that holds true for the whole run or if this an outlier day because it was more workshop-oriented and the expo floor wasn’t open.

i was going to write some reactions to an observation that postgresql has no bug tracker and its discussion last week, but lost the spark and abandoned the post after a few days. but today i ran across a quote from linus torvalds that neatly sums up my thoughts:

We’ve always had some pending/unresolved issues, and I think that as our tracking gets better, there’s likely to be more of them. A number of bug-reports are either hard to reproduce (often including from the reporter) or end up without updates etc.

before there was a bug tracking system for mysql, there was a claim that all bugs were fixed in each release (or documented), and there has been a lot of pain in seeing how well that sort of claim stacks up against a actual growing repository of bug reports. if the postgresql project were to adopt a bug-tracking system, i am certain that they would find the same issue. before long, they would be planning bug triage days just like every other project with a bug-tracking system seems destined to do.

another good email from linus about these issues was pointed out by a coworker, but this part in particular caught my eye:

Same goes for “we should all just spend time looking at each others patches and trying to find bugs in them.” That’s not a solution, that’s a drug-induced dream you’re living in. And again, if I want to discuss dreams, I’d rather talk about my purple guy, and the bad things he does to the hedgehog that lives next door.

the procedure at mysql for code reviews is that either two other developers must review the patch, or one of an elite group of developers who are trusted to make single reviews. then the developer can push their changes into their team trees, taking care to have merged the changes correctly in anywhere from one to four versions (4.1 and up).

this is a huge amount of friction, and is one of the most significant problems causing pain for mysql development. two reviewers is just too high of a bar for most patches, and having the rule makes the reviews rote and less useful. there is also an unreasonable amount of distrust being displayed by this procedure, that says that developers can’t be trusted to ask for help when they are unsure, but should feel free to make the occasional mistake by pushing something that isn’t quite right.

i wonder if we could be taking better lessons from linux’s hierarchical development model, with the pulling of code up through lieutenants to a single main repository, rather than the existing model that involves every developer moving their own stones up the pyramid. it would require some developers (more senior ones, presumably) to spend more of their time doing code management as opposed to actual coding.

monty is not particularly happy with the state of development of his brainchild now. would he be happier if he were in a linus-like role of rolling up patches and managing releases?

i wish had the patience to write at less length and greater coherence about this.