nik9000

joined 2 years ago
[–] nik9000@programming.dev 3 points 1 year ago

The point of the license combination they use is to allow the enterprise version to be open and live in the same repo as everything else. Dunno if that's what they do, but that's why the elastic license exists.

[–] nik9000@programming.dev 10 points 1 year ago

The only surefire way is to read it all. And understand it all. That ain't happening though. So you decide how much to do.

You should figure out how many people are landing patches and get a rough sense of why. Same for folks filing issues or talking about the project in general. Maybe you trust one of the contributors for some reason. Either way, you want to know how alive the project is.

You could land a patch.

You could spot check parts of the code.

You could run vulnerability scanners on it.

I dunno. It's hard.

[–] nik9000@programming.dev 4 points 1 year ago

It really is. It'd make a wonderful assignment in a second level programming class.

We use hyperlloglog++ for this because it's mergable across nodes and threads. I haven't thought much about combining this one.

[–] nik9000@programming.dev 1 points 1 year ago

I'm not sure I'd attach any meaning to real names online. There's a whole group of us whose online names are just things they thought were neat when they were 12. And they've just stuck forever. There's lot of reasons.

But otherwise, yeah. I'll spend ten minutes looking up someone's online profile. Mostly for GitHub if I can find it. If someone's commenting on public prs and seems nice that's a big signal.

[–] nik9000@programming.dev 1 points 1 year ago

I agree. Light touch until you have a bunch of changes landed.

I was a professional open source contributor for a while. Still have the same job, but the license changed. Culture still quite similar though.

[–] nik9000@programming.dev 1 points 1 year ago

We squash. I'm not really interesting in your local journey to land the change. It's sometimes useful during review, but after that it's mostly the state of the main branch I care about. It's what I need to bisect anyway.

I don't like commits that are just references to issues. Copy the issue into the commit message so git blame tells you something useful. Unless it's just closing a simple big. Then the title and issue reference are plenty.

Depends on the project I imagine.

[–] nik9000@programming.dev 4 points 1 year ago (5 children)

I wonder what my last commit at each job was. I'll bet it was boring. About 10% of my commit messages are genuinely interesting.

[–] nik9000@programming.dev 1 points 1 year ago

I review a ton of code and have a bunch reviewed in turn. I don't remember that last time I've had this come up. Either direction really. I guess I'm lucky. We just split naturally in similar places.

[–] nik9000@programming.dev 1 points 1 year ago

I think it's a bad analogy because it'll distract some people.

[–] nik9000@programming.dev 11 points 1 year ago

It just doesn't come up all that much. Folks live without knowing they are different.

And it is on a spectrum. Some folks is nothing others are can force a few pictures if they have to but aren't clear. I dunno.

[–] nik9000@programming.dev 6 points 1 year ago (1 children)
view more: ‹ prev next ›