This seems to kill travis :P can you investigate please

To be clear. This can't go into 3.3.x since it's a new feature.
For 3.4 the deadline for new features was two weeks ago, so currently it could go into 3.5 earliest.

From what I see this PR lacks the SQL files and probably only works because it has sort of a fallback worked into it at https://github.com/joomla/joomla-cms/pull/3753/files#diff-79e4a413a753146b39c7b946d94a7dfcR146. Basically doing the exact same hardcoded thing in cms.php we try to solve to begin with.

So any testing at the moment is useless.

I'm also not sure how much I like that the observers can be put into two different tables (#__extensions and #__content_types). Overall it looks a bit complicate for what it's trying to solve. I fear that in the end it's even harder to setup tags and content history than it already is.

I thought david said on skype yesterday the 3.4 deadline was tomorrow? (11th?)

But I have to agree I don't see what the need is the the #__extension table to use the observers stuff. Why can't we just use it in #__content_types?

And I kinda agree with Thomas that whilst this is 'architecturally' more correct it does appear to make it even harder for users. Let's be honest for a given extension there's gonna be tags stuff hardcoded into views etc. so it no longer is a proper observer even if the storing of tags into the relevant tables might be.

But I'll give some faith for now. Please can you fix up travis and include the SQL files so we can do some proper testing :P And I'd be interested to hear the explanation as to why we need to store the observer in two different tables

I thought david said on skype yesterday the 3.4 deadline was tomorrow? (11th?)

Tomorrow is final date to merge new features. May 28th was the final date to propose new features. 16th should be first beta. See http://developer.joomla.org/news/583-announcing-joomla-cms-3-4.html.

But I have to agree I don't see what the need is the the #__extension table to use the observers stuff. Why can't we just use it in #__content_types?

Actually, I think the #__extension makes more sense than #__content_types. The observers aren't tied to a content type. It happens to be fior tags and history, but the content type is really only a parameter passed to it. The observers could be used for other things as well which aren't tied to a content type.
On the other hand, I think they don't even necessary need to be tied to an extension. And there are multiple observers for extensions and content types.
I tend to think if we want to have this database based, the simplest thing would be to have an own table for it and work from there.

@beat it looks like you abandoned this after submitting it as there was no reply to the request to fix travis and add the sql. I am setting it to information required and it will be automatically closed if there is no reponse

Closed - it can always be reopened when updated