Extensionalize phpBB

[javiexin]

While I do understand your concerns, I think that they highly influenced by your last statement:

And the extensions team is already understaffed and overwhelmed with all of its current extensions duties.

Let's not try to be influenced by the current status of the teams, and try to think positively, even if at the end, the choice is to do nothing.

Let me try to rebate your points.

It makes releases more difficult to ship as we would be required to also manage/release multiple extensions with a phpBB release to ensure users are kept up to date, as well as distribute them with every release, making an already dificult task even more difficult for those involved in releases.

Not necessarily. The code is released today with every release, and distributed together. That does not need to change at all. Or, in case it does, it would be the same situation as with any other extension at a release change: if there is no BC break, no problem. At least within minors, this should never be an issue, unless something specific has changed, and in that case, the extra effort would be required either way, with or without extensions.

It degrades testing phpBB. phpBB's core code is continuously tested in its entirety on three separate development branches. Some minor change here could create a major bug there, and if all these componenets are removed, some phpBB development regressions will no longer be detected, and the burden on the support team will sky rocket as they get bombarded by unforseen bugs and support topics, and have to scramble to figure out why the problem is occurring by dealing with a littany of separate extensions..probelms that could have been detected during testing.

Again, not necessarily. What blocks the possibility to test the core WITH THE CORE EXTENSIONS together? The only requirement would be to have extra tests to enable/disable each new block independently, nothing really fancy. Note I have renamed these from "official" to "core" extensions, so that it does not give the impression that they are at the same category: they do not have to be treated the same way as the current official extensions are treated.

It also makes testing and devloping extensions immensely difficult. Extensions are always developed and tested and validated against fresh phpBB installations. Removing all those componenets from the core means extensions will not be tested in the complete environment they are currently. It also measn to pull off testing in a "fully loaded" board would make the lives of the testers enourmously tougher than it already is. And indicidual developers will most likely not be developing while on a "fully-loaded" install either.

The testing environment is decided by the Validation team. This would mean a change? Well... maybe, maybe not. Testing could be defined to be done with the "core" extensions enabled, or with them disabled. And in any case, the installation should not be much more difficult. Already today, the core is shipped with an enabled extension, that may be disabled by the admin later on. These could be the same, so would make NO difference when setting up a new environment for testing.

Also extensions that are continuously unit-tested will not be able to detect any bugs associated with those extensions, as they won't be part of the core phpBB installation that is used during unit testing, leading to extension authors having to support multiple new issues unforeseen, making their motivation to do this work wane.

Same assumption as above: these core extensions could/should be part of the core testing environment, so this should not be the case.

It also ensures the componenets will probably go stale as once it's out of the core, it will no longer be a primary responsibility of the development team. And the extensions team is already understaffed and overwhelmed with all of its current extensions duties.

Team definition and responsibilities may be redefined as well: if the core is smaller, the team to develop and maintain it could be smaller as well, and viceversa, if there is a new block component (core extensions), there could be a new team, or keep the responsibility in the core team, or move it to the extension team and grow that team. That is an organizative issue, not so much related to what I am proposing here, that is more architecture and componentization of the core.

Let's not focus on the organization issues for a moment, please. I understand that, in the end, for this proposal to be successful, this will have to be solved. But before we go there, we should decide whether FROM THE TECHNICAL perspective, this makes sense or not. Once that is clear, and if the view is generally positive, then we could (and should) worry about the organizative issues. But why go there, if we are still very far, in terms of conceptualizing and technically deciding about these?

Thanks a lot,
-javiexin

[david63]

There is one issue that would be problematical with the current update/upgrade procedure and that is that is that extensions that need updating would need to de disabled first and then re-enabled.

[javiexin]

There is one issue that would be problematical with the current update/upgrade procedure and that is that is that extensions that need updating would need to de disabled first and then re-enabled.

Only those that have new migrations, or very special cases of changes in ext.php. Otherwise, it is not needed. For those case, it is possible to include a new migration that if the extension is enabled, disables it and then reenables. Very simple migration I think.

And anyhow, I think I remember seeing some code in the core to do exactly that: disable extensions before an upgrade, and then reenable them after (I think it is in the 3.1 to 3.2 upgrade, but I'm not sure).

And in any case, this is the kind of things that should be discussed after we have a clear picture of whether this is good or bad from a technical / architectural point of view.

Regards,
-javiexin

[3Di]

Interesting discusssion IMO. Me following this one.

There are pros and cons, yet the balance needs a clarification.

[david63]

There is one issue that would be problematical with the current update/upgrade procedure and that is that is that extensions that need updating would need to de disabled first and then re-enabled.

Only those that have new migrations, or very special cases of changes in ext.php. Otherwise, it is not needed. For those case, it is possible to include a new migration that if the extension is enabled, disables it and then reenables. Very simple migration I think.

And anyhow, I think I remember seeing some code in the core to do exactly that: disable extensions before an upgrade, and then reenable them after (I think it is in the 3.1 to 3.2 upgrade, but I'm not sure).

And in any case, this is the kind of things that should be discussed after we have a clear picture of whether this is good or bad from a technical / architectural point of view.

Regards,
-javiexin

I agree that it can be done - all I said was that with the current update/upgrade routines this is not possible, but what I would add that having seen the [large] number of users that have problems updating/upgrading then the update/upgrade routine needs to be simplified not made more complex.

[Ger]

I like this idea actually. Now of course the choices of which function should be extensionalized and which shouldn't is open to debate. But something that's mentioned quite often are the COPPA functionality (USA only) and birthdays. Those two aren't really biggies I think so you might consider moving those to an extension in let's say 3.3 or 3.4. Take one or 2 features for each upcoming version and I think it can be handled very well.

[canonknipser]

I like this idea too - and it is already done with 3.2 (Vigilink extension - which is a official extension, but not listed in the extensions DB?). So this is no "new stuff"

[DavidIQ]

I'll quote this for emphasis as this will be our current official position on this idea and the responses/breakdown that have attempted to address these concerns have fallen quite short of that:

The very idea of this makes everything many orders of maginitude harder to maintain, as far as updates, compatibility, development, usability and language translations go.

It makes releases more difficult to ship as we would be required to also manage/release multiple extensions with a phpBB release to ensure users are kept up to date, as well as distribute them with every release, making an already dificult task even more difficult for those involved in releases.

It degrades testing phpBB. phpBB's core code is continuously tested in its entirety on three separate development branches. Some minor change here could create a major bug there, and if all these componenets are removed, some phpBB development regressions will no longer be detected, and the burden on the support team will sky rocket as they get bombarded by unforseen bugs and support topics, and have to scramble to figure out why the problem is occurring by dealing with a littany of separate extensions..probelms that could have been detected during testing.

It also makes testing and devloping extensions immensely difficult. Extensions are always developed and tested and validated against fresh phpBB installations. Removing all those componenets from the core means extensions will not be tested in the complete environment they are currently. It also measn to pull off testing in a "fully loaded" board would make the lives of the testers enourmously tougher than it already is. And indicidual developers will most likely not be developing while on a "fully-loaded" install either.

Also extensions that are continuously unit-tested will not be able to detect any bugs associated with those extensions, as they won't be part of the core phpBB installation that is used during unit testing, leading to extension authors having to support multiple new issues unforeseen, making their motivation to do this work wane.

It also ensures the componenets will probably go stale as once it's out of the core, it will no longer be a primary responsibility of the development team. And the extensions team is already understaffed and overwhelmed with all of its current extensions duties.

tldr;
I wouldn't spend too much time thinking about or even working on this idea as there are no plans to implement it at this time nor in the near (next 5-10 years) future. Good idea? Maybe on paper. In practice (at least right now) this is going to be a nightmare for maintenance, testing, releases, and many other things.

[Ger]

If that's the case you might just as well lock this topic.

[DavidIQ]

Agreed. Locked.