On Thu, May 28, 2015 at 11:26 PM, Guillaume Lelarge <guilla...@lelarge.info>
wrote:

> Le 29 mai 2015 8:01 AM, "Fabien COELHO" <coe...@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".

Cheers,

Jeff

Reply via email to