[Epo-ec-advisors] Getting Started

[Chris Prather]

I was traveling this weekend and didn't get a chance to reply. I also
didn't notice that yuval had missed the list with his reply.

On Fri, Jul 3, 2009 at 7:30 PM, Yuval Kogman<nothingmuch at woobling.org> wrote:
> For step 2 I would like to see a separation in each of the domains
> into two "stages".
>
> The way I see it, the first category is modules that are correct and
> you should always use (e.g. for defanging HTML, consider the broken
> modules vs. the ones actually designed to handle XSS. Obviously we
> should review one and recommend it for reasons of safety/correctness).
>
> The second category is one that are generally a good idea, but require
> emotional investment. A good example of a module that is completely
> unnecessary but does make things a little easier is Crypt::Util. This
> is a convention layer (the rails meaning of convention) that should be
> easily available but not required to make use of the EC.
>
> Another example is the Email stuff. If you are starting from scratch
> you probably want to use Email::MIME::Kit since you can flex yourself
> around its requirements, but that's not always an option if you need
> to fit in an existing framework, you need Email modules from the first
> category, simple, reliable, and debugged, but also as policy free as
> possible.

Yes I think.

Your category 2 here seems to have two purposes.

1) Modules that are sugar layers / shims to make things easier like
Crypt::Util or possibly JSON::Any

These should be treated like category 1 modules and either go in or
not. If they provide enough convenience then that's worth it.

2) Modules that are robust but are flawed in some way (Email:: seems
to be a place for this) where there isn't a clear winner in category 1
yet but is still a vital category.

These need to be looked at closer. They are the ones I was talking
about identifying what *can* be done and having the EPO allocate
resources to make they fit into "should just be used". Our job is to
make it as easy as possible to make the decision of what to be used.
One of those is

> The last thing I'd like is that the review process for these be kept
> open and logged, especially for the first category stuff. If we know
> that e.g. Email::Blah is broken with respect to unicode headers, that
> is something that can be non obvious when making a decision to use the
> module, but for which the user pays dearly later. Being able to look
> at the extended core documentation and find out why a certain module
> was accepted (and why others were not) would make the extended core
> much more useful than being a list of defaults in my opinion. We have
> to do the research anyway, so might as well.

The review process is *definitely* going to be open and logged. The
reason I started an advisers list was actually to make the level of
bike shedding very high quality (Sherwin Williams paints!) and to make
the process as well documented as possible.