Wedge

Yes and no. Being open means you open the doors to a potential flood of submissions. You then have the joy of wading through the submissions in the hopes of finding good things. If you get a collection of great coder submissions, great, but the odds are not in favour of that being the case, given what has been approved as mods in the past.

Seriously, being open is not the magical panacea it's supposed to be. Being open means you get more input. It doesn't mean it's any *better* input. If anything I'd almost say that it will eventually dilute things because there will be pressure to accept patches that aren't up to snuff.

Consider the past of SMF. It was hard enough getting to be a beta tester, let alone a dev badge. Consider the people who earned that badge. Consider also the people who've submitted patches in the past to SMF, and how few of those were historically accepted. It's not merely a lack of time that caused all those things to be the case, it was the overall low quality of submissions.

In fact, going back it was pretty much only the people who were team members who ever got patches approved, and even then you're pretty much talking about the Cust. team people who ever got anything into the core who weren't the dev team. I haven't been through 2.1 but I suspect the people whose patches have been approved are the people who didn't make it into the Cust. team primarily out of politics or not wanting to be involved, but the same people nonetheless who would have been eligible anyway.

In short: I don't think it's really as open as might want to be believed[1] and while I want to believe the best, I'm not sure it's the right path for them to take.

To be brutally honest, I want to be wrong about this. But I want to see SMF take their main repo public and see what happens, I see no reason to think our experience will be substantially different. Everything I'm predicting is almost certain to come true sometime after SMF makes the 2.1 repo public, and I do not want us to fall into the same trap.

1.	It's not even under the main public account but away in someone else's repos. Security by obscurity, you might say.

No, but you get a lot of data to work with to be able to understand how running a larger forum is likely to handle the extra load.That's a very good question. What it means to me is that MessageIndex.php needs an overhaul, possibly loadBoard() needs to identify the type of board involved and when we would otherwise divert to MessageIndex, we figure out which file needs to be loaded for that type of board.I don't think it's true, I know it is, but I also know the author's an idiot in the first place - SELECT * and SELECT field, table.* levy their own issues, and I suspect something interesting would happen if the author didn't just blindly select * from anywhere.

Anyway, yes, the point is correct: if you do a query where you're sorting by any column and there's a TEXT or larger field in there, it will generate a disk-based temporary table (this is what a filesort is). Getting around it using a subselect is an interesting way of doing it, but essentially yes it's correct, it fools the query parser as to how the table is generated and it means it isn't implicitly a filesort. At that point you just have to hope MySQL can get enough memory to do it in memory otherwise you end up with a filesort anyway.

It's also why Display, for example, gets the message ids first, then fetches messages separately.

It is referring to pull requests - from the perspective of contributors, they're pushing to the project and expecting the project to take it onboard.

Nothing says 'get stuffed' than not accepting any inward contributions, but if there's no obvious way to do that, that's actually better than appearing to solicit such things without accepting them.

Hmm, I need to try it with both my IPS screen on my MacBook and perhaps the Samsung SyncMaster 193 I have (it runs to 1280x1024 though it's still basically 5:4 as a screen)

Yeah, that's the one, it's pretty insane and holds together by miracles I'm sure. It's still running on Apache for example >_> (Liroy needs to move that to nginx ASAP)

You're the one who reported it - where drafts get saved even when they shouldn't be - the result is phantom rows that shouldn't really be saved in the first place.If you mean the regular cache, there should be no need to do that automatically most of the time, it should just work with older data just being purged over time.

If you mean cases like this, I'd suggest not doing that on an automatic fashion. I'm not sure it's ever going to be a problem.

As per http://stackoverflow.com/questions/6130672/mysql-auto-increment-primary-key-running-out there are notes about keeping the primary key as small as possible (especially on InnoDB), and that's important as that's now the default in MySQL. Let's leave it as is and we can deal with it if and when we actually get near to those limits.

I envision that it isn't really a problem if we end up avoiding making rows we don't need - right now there are phantom rows being introduced that leak ids even faster. If we reduce that from happening, we reduce the problem anyway.

But even as I've typed this, I can see we're only onto #8556 out of how many thousands of millions...?