catch, does https://drupal.org/node/2151427 needs your approval? https://drupal.org/node/2151427 => Convert COMMENT_NOT_PUBLISHED & COMMENT_PUBLISHED to a constant on the comment interface [#2151427] => 4 comments, 1 IRC mention andypost: if the existing constants are left in, not at all. catch, also I've compiled a list of changes about comment and history module https://drupal.org/node/1847540#comment-7910961 https://drupal.org/node/1847540 => [META] Clean up comment module tests and decouple from node [#1847540] => 8 comments, 3 IRC mentions andypost: if they're killed, it probably does need a committer I guess. catch, this summary have proposed changes, but the one ^^ is going to drop this catch, I and larowlan needs some feedback to move forward with comment module clean-up, but mostly all changes affects interfaces catch, please comment the meta with your suggestions andypost: so adding stuff to the various comment interfaces, I think that's fine before beta. andypost: just leave the old functions there for bc - calling out to the new methods. get it andypost: comment_entity_statistics - if that's a performance improvment then it'd be fantastic. catch, but the constants better to clean-up before beta andypost: yes but we can have two constants that mean the same thing, one class and one not. andypost: so it's no problem to add. andypost: changes to individual entity interfaces (as opposed to the ones they inherit from) after beta I'm not sure about at this point. catch, ok, will revert old ones back andypost: we can open a separate issue to remove - that might still be OK, but means adding the new ones needs zero approval except for normal RTBC. catch, awesome! and about history module the same, is it still ok to change storage? andypost: the schema of {history} or the way it's accessed or both? catch, https://drupal.org/node/1029708 I think we could change storage and add historyManager to work with any entity, also preserve old procedural wrappers for bc https://drupal.org/node/1029708 => History table for any entity [#1029708] => 67 comments, 10 IRC mentions catch, but this all depends on schema change andypost: that's harder. Probably that'd have to go in before beta, but it wouldn't block beta. andypost: if the service was added first, and was bc-compatible with an entity-type agnostic one, then it could technically go in after beta with the schema change - since the schema wouldn't be part of the API. andypost: but that is where it starts getting trickier in terms of what's an API change vs. not. catch, agreed, so what should I do to get rid of COMMENT_NOT_PUBLISHED & COMMENT_PUBLISHED? tag needs commiter feedback and assign to you ? andypost: API change - doesn't have to be assigned to me. catch, so who can aproove? andypost: probably postpone on the other issue. This comes down to what we do with @deprecated stuff in general which hasn't been sorted out yet. andypost: any of me, Alex, Dries or webchick. andypost: but for me it's related to https://drupal.org/node/2042165 https://drupal.org/node/2042165 => Consider adding a 'deprecated' module [#2042165] => 13 comments, 4 IRC mentions hm, interesting stuff andypost: i.e. what to do with the dozens of @deprecated functions - do we leave them in deprecated, rip them out before beta etc. they really should stay until D9 otherwise they aren't exactly deprecated msonnabaum: well some stuff that's marked ought to be nuked. msonnabaum: some stuff doesn't matter. Also some things aren't marked but should be nuked anyway. right, we need another word for those ones catch, so preferable way - add new stuff with proper interfaces and leave old wrappers Like variable_*() right, which we should just move to the installer and be done with it andypost: yes, and mark the old stuff @deprecated.