Wedge

*shrug* I think this is one place we will have to agree to disagree.

Did you watch the presentation where he actually outlines the flaws he perceives in the GPL? Not all of them are related to length and readability.

It's not what they've done, it's why they've done it.

GPL has always considered itself to be the ultimate copyleft licence, it's supposed to be a shining example of strong copyleft. It strikes me as ironic that someone has dared to fork it, and actually attempt to reduce its copyleft status because as per the presentation from the author, strong copyleft actually doesn't work.All I'll say is: http://www.gnu.org/licenses/why-not-lgpl.html - while they admit for some libraries, LGPL is a fine fit, they'd much rather everyone just sucked it up and went GPL. That is what they're saying: note how they actually go on to say that 'when a library provides a significant unique capability' it should be GPL, such that anything that's reasonably generic, they don't really care, but when it would be advantageous to their cause, it would be better to be GPL. That's not a definition of freedom in my book.

Did you need another reason not to use Github?

I do not want a full-on reputation system in the core, which is what you're proposing. I'm not against the idea in principle, and there are certainly merits for it for some kinds of communities - but as I see it, more communities would benefit from keeping it leaner rather than more thorough, and I'd much rather see something as thorough as what amounts to a full on rep system be a plugin.

There is also a secondary consideration here, my gut is telling me that anyone who wants a rep system as complex as this is also going to want to seriously customise it, and to me that also says it's going to be a support issue. Putting it into a plugin keeps is more self contained.

Do it. It works very well for me.

I haven't looked at 2.1's source much (literally last looked ages ago), would rather not do so, ironically out of a weird sense of respect. I figure we branched off when we did and I've only re-incorporated stuff back in from the patches after we branched, I see it that we went our separate ways and that was that, you know?

It looks really nice :)The PM notification is one of the more sucky things in SMF, it's just a bare JS alert().It uses silly[1] non-linear non-numbered revisions. That enough for you? :niark:That's generally true but honestly I'm not bothered myself about whether it's on Github or not. I find it tends to get in my way when trying to do anything.For minor components you probably would be better served with your own repo, e.g. the selectbox.

1.	I still find it silly even though I can make several good arguments that it isn't silly.

Sadly it's not quite that simple. There are two kinds of schema changes, some are essentially free because they just update the table definition, e.g. changing a mediumint(5) to a mediumint(8) is free because it's just updating the .frm file (for MyISAM, though it's still true for InnoDB too)

The other kind is where it is not free, because it requires rewriting all the data in every row to align it to the new size. Changing the size or type of columns (mediumint to int, or the other way for example, or changing the type from numeric to textual etc) is very expensive on large tables as a result - and naturally it's usually fully table locking in the process. (Certain InnoDB operations can be done without it being a full table lock but generally assume it is)

Also note that adding a column to an existing table has exactly the same problem. For most tables it's not preposterously expensive in most cases, because in most cases people with 100k+ posts don't generally go modifying their DB too much unless absolutely necessary because once they get to that size they're already aware of the limitations.No, it's not compressed, but it is byte-packed, meaning that fields that don't need full bytes don't generally consume full bytes, but they pack all the fields in to use the least number of whole bytes.

There's not really a great amount of compression you can do on three bytes.id_topics appear in the indexes in multiple places. Take wedge_messages, of the litany of indexes that table has, four of them have id_topic as part of those indexes, and as a result of that, expanding the id_topic field to 4 bytes means we don't lose an extra byte per row, we lose that multiplied by 5 (1 for the row, 4 for indexes), so we gain 5 bytes per message, just in that one case, and in the case of indexes, we have a vested interest in keeping them lean.

mediumint unsigned is fine for topic and media item ids as far as I'm concerned.

The number of bytes is not a huge issue; MySQL quite happily uses 1, 2, 3 and 4 byte fields with impunity. Since MySQL does even have bitwise fields that actually work at the bit level, and it packs rows itself, it's not a really huge issue.

Of a more practical issue is the fact that all the indexes which use that field (of which there are more than one AFAIR) will all remain the same size rather than growing.