Core vs. Extensions

Discuss general development subjects that are not specific to a particular version like the versioning control system we use or other infrastructure.
User avatar
callumacrae
Former Team Member
Posts: 1046
Joined: Tue Apr 27, 2010 9:37 am
Location: England
Contact:

Re: Core vs. Extensions

Post by callumacrae » Sat Aug 09, 2014 3:07 pm

+1 to removing as much as possible (even stuff that the majority of boards use; they can just be distributed already enabled). Modular = good
Made by developers, for developers!
My blog

User avatar
EXreaction
Registered User
Posts: 1555
Joined: Sat Sep 10, 2005 2:15 am

Re: Core vs. Extensions

Post by EXreaction » Wed Aug 13, 2014 11:46 pm

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.

User avatar
callumacrae
Former Team Member
Posts: 1046
Joined: Tue Apr 27, 2010 9:37 am
Location: England
Contact:

Re: Core vs. Extensions

Post by callumacrae » Thu Aug 14, 2014 9:11 am

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.
Made by developers, for developers!
My blog

User avatar
hanakin
Infrastructure Team
Infrastructure Team
Posts: 853
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: Core vs. Extensions

Post by hanakin » Thu Aug 14, 2014 9:30 am

callumacrae wrote:+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
3.2 Release Manager
3.2 Release Manager
Posts: 298
Joined: Sun Apr 13, 2014 1:40 am
Location: Paris

Re: Core vs. Extensions

Post by Nicofuma » Thu Aug 14, 2014 10:21 am

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.
Member of the phpBB Development-Team
No Support via PM

code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: Core vs. Extensions

Post by code reader » Thu Aug 14, 2014 3:39 pm

EXreaction wrote: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.

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1787
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: Core vs. Extensions

Post by DavidIQ » Thu Aug 14, 2014 5:06 pm

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.
Image

code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: Core vs. Extensions

Post by code reader » Thu Aug 14, 2014 5:18 pm

DavidIQ wrote: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.

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1787
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: Core vs. Extensions

Post by DavidIQ » Thu Aug 14, 2014 5:36 pm

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.
Image

User avatar
bantu
3.0 Release Manager
3.0 Release Manager
Posts: 557
Joined: Thu Sep 07, 2006 11:22 am
Location: Karlsruhe, Germany
Contact:

Re: Core vs. Extensions

Post by bantu » Thu Aug 14, 2014 5:56 pm

code reader wrote: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.

Post Reply