Le 29 mai 2015 8:01 AM, "Fabien COELHO" <coelho@cri.ensmp.fr> a écrit : > > >> FWIW, I don't mind which one we put in core and which one we put out of >> core. But I like Joshua's idea of getting rid of contribs and pushing them >> out as any other extensions. > > > Hmmm. > > I like the contrib directory as a living example of "how to do an extension" directly available in the source tree. It also allows to test in-tree that the extension mechanism works. So I think it should be kept at least with a minimum set of dummy examples for this purpose, even if all current extensions are moved out. >
Agreed.
> Also, removing a feature is a regression, and someone is always bound to complain... What is the real benefit? ISTM that it is a solution that fixes no important problem. Reaching a consensus about what to move here or there will consume valuable time that could be spent on more important tasks... Is it worth it? >
It would be less confusing for users. Contrib modules seem to be first class extensions, leaving doubt on other extensions.
Presumably there are still going to be some extensions maintained by -hackers, and some not. I don't think we are going to change that, so the difference will still need to be explained, regardless of what words are used. And people *should* have doubts about other extensions. Couldn't any talented programmer write an extension which gives them a backdoor into the deployer's system, and then upload it to github?
I would certainly be cautious about installing any old extension I found some some place on the internet.
But the fact they aren't in core make them not fully trusted by some users.
Would it help if we called it "base" or "minimal" rather than "core" in the docs? (And called 'contrib' something different as well? The docs already do call it "Additional Supplied Modules" and use "contrib" only when referring the the directory, not the concept.)
Trying to explain all that in a training is a PITA. It would be much less confusing if they were either in core or in their own repository.
Several of the contrib modules should be kept in tight sync with src or else testing and debugging would be a disaster. Putting them in different git repositories wouldn't work well. Unless those would among the ones moved to "core".