Core vs. Extensions

[callumacrae]

+1 to removing as much as possible (even stuff that the majority of boards use; they can just be distributed already enabled). Modular = good

[EXreaction]

I agree that in general, a more flexible and smaller core package is better and that we could really remove a lot and put them into extensions. The only issue is we're not properly positioned to maintain those extensions and I wouldn't be for removing features most of the time if they're not maintained officially as an extension.

To just throw it out there, this may be a possibility in the distant future with the official extensions team working closely with the development team. Neither team has the resources at the moment for such an undertaking, but if that changes I think it would be a great idea.

[callumacrae]

You have the resources to maintain these features in the core, but not as extensions? :S

Loads of NodeJS libraries have extremely small code bases (The entire GulpJS source is 63 lines long, and a good chunk of that is deprecated notices, and even Express is pretty small after they moved the middleware to other libraries). It works damn well.

[hanakin]

+1 to removing as much as possible (even stuff that the majority of boards use; they can just be distributed already enabled). Modular = good

+1

[Nicofuma]

The real issue will be with the dependencies and the maintenance of the third parties because with this system the extensions will depends on many others extensions (why not, it could be a good thing) and so, inevitably, an official extension will depend of one future of a third party extension for which the team will have to give support (and maybe maintain this extension themself if the original maintainer stop). If you see what I mean.

Symfony could have exactly the same issue but they don't have any official extensions, instead they have a bunch of Components and Bridge which are not Bundles and don't depend on any Bundle.

I could be a good idea, but for now the core is not ready and if we want to take this way one day we will have to clearly define what should be in the core, what should be an official (or core?) extension and on what these extension could depend.

[code reader]

I agree that in general, a more flexible and smaller core package is better and that we could really remove a lot and put them into extensions. The only issue is we're not properly positioned to maintain those extensions and I wouldn't be for removing features most of the time if they're not maintained officially as an extension.

To just throw it out there, this may be a possibility in the distant future with the official extensions team working closely with the development team. Neither team has the resources at the moment for such an undertaking, but if that changes I think it would be a great idea.

but this is precisely the point i was trying to make:
in the current state of affairs, it seems that the idea is that "extension team" will deal with everything which is extension, and "core team" will deal with everything which is core.

IMO, this is just silly: it's like arranging the agriculture department based on the color of the produce, so you'll have one office handling tomatoes and cherries, and another office handling cucumbers and avocados. red and black plums will be managed by two different offices, and don't even ask about the peppers, whose management will have to be broken across six or seven different offices,,,,

the correct distinction should _not_ be according to the packaging:
what you call now "extension team" should really be called "community source team" or somesuch, 'cause, this team deals with "sanctioning" or verifying and approving community-contributed code. the fact that this code comes in the form of extensions is coincidental.
code that's packaged as extensions which is *not* "community sourced" does not belong to this team. the core team should manage its own code, and should not be limited to packaging all its output in one monolithic piece called "core" if it does not happen to belong there. core team should package its code in extensions when it makes sense to do so, and when it does, this doesn't imply that core team relinquish control of this code to someone else.

we should not conflate the question "how the team should be arranged" and "how the code should be arranged".
packaging all the code that's written by the core team in one monolithic "Core" package makes as much sense as arranging the agriculture department by produce color.

peace.

[DavidIQ]

What should we name the Styles Team then?

FYI the Extensions Develolment Team is a sub-team of the Extensions Team so it is under their control and supervision, not its own entity. Therefore the Extensions Team is involved in creating official extensions as well besides validating community extensions. To my knowledge there has never been any perceived confusion as to what the Extensions Team, the Extensions Development Team, and the Development Team do prior to the start of this topic and I doubt there is any.

[code reader]

What should we name the Styles Team then?

FYI the Extensions Develolment Team is a sub-team of the Extensions Team so it is under their control and supervision, not its own entity. Therefore the Extensions Team is involved in creating official extensions as well besides validating community extensions. To my knowledge there has never been any perceived confusion as to what the Extensions Team, the Extensions Development Team, and the Development Team do prior to the start of this topic and I doubt there is any.

well, this may be the current structure and model, but IMO this structure is a mistake.
"official extensions" should come from the core development team, and what you call now "extensions team" should concentrate on community contributed code. i also expressed the opinion that it should better be renamed, so the name will reflect its true role.

the whole point of opening this topic was to express this opinion, and start a discussion about what's the right thing to do.
the structure you describe is, IMO, the wrong thing to do.

peace.

[DavidIQ]

While I don't necessarily disagree with you on everything you've said in your first post I definitely don't think that right now nor anytime soon is the right time to do such a structure change both in the organization (teams) and in the code. It is a pretty big culture change internally and externally (community) to go with a "basics only" core and have everything as extensions. If we considered doing something like that it wouldn't fit in too well anyways until a major re-write like maybe 4.0 or beyond.

[bantu]

the core team should manage its own code, and should not be limited to packaging all its output in one monolithic piece called "core" if it does not happen to belong there. core team should package its code in extensions when it makes sense to do so, and when it does, this doesn't imply that core team relinquish control of this code to someone else.

This is already the case. The development team will package code into extensions as it sees fit. Control over said code is relinquished (or not) as the development team sees fit. This just hasn't happened so far because we were busy with adding infrastructure making extensions possible.

Ripping out features into extensions is a good idea in my opinion, but a different story. The code properties of legacy code (spaghetti code, non-explicit dependencies, lack of tests, etc.) make doing so rather difficult. I personally would suggest to rather spend time on making the extension system itself more robust in the near future.