[Epo-ec-advisors] Some thoughts on areas to address in the EC

[Chris Prather]

On Fri, Jul 17, 2009 at 8:49 AM, Adam
Kennedy<adamkennedybackup at gmail.com> wrote:
> 2009/7/17 Matt S Trout <m.trout at shadowcat.co.uk>:
>> And, of course, the difference here is we don't need consensus that a
>> particular way is -best-, only that it's -popular- and -good-. This has to
>> be an exercise in shipping rather than one in perfectionism.
>
> Correct.
>
> However...
>
> I may be reading people wrong, but I do think I'm already seeing the
> emergence of similar tendencies.
>
> "On top of that, I'm working on MQI (Message Queue Interface),
> which is intended to be DBI for messaging with a standard API via a
> factory class and MQD (driver) layers on top of each protocol. Thoughts?
> Does that sound like a good way forward?"
>
> This line of thought can quickly become "And we should build it and
> bundle it into the core"

I have said privately and will say publicly that I will not trust
newly-written code. If people on this list do not use a piece of code in
production[1] or tell me that a piece of code is worthy it doesn't go in. The
goal here is to produce a snapshot of what a Perl Company uses for development
and production systems.

I spent some time looking through the archives of the P5EE project, and I
think this is exactly their point of failure. Even when they were reaching for
the TIMTOWTDI approach they were discussing writing shim layers to make things
integrate. I have absolutely no intention of writing new code as part of this
project. We *do* have in our scope the ability to identify places that new
code could be written and recommendations to the EPO about grants and whatnot,
but even should someone write an entirely new project (like MQI) until it has
proven itself with a sufficient subset of this list as being worth
recommending ... it doesn't go in.

Finally I wanna make more clear the relationship between this list and the
EPO-EC Working Group. The Working Group is the one who has the task of
creating a product out of CPAN and the recommendations on this list. If the
Working Group fails to ship a product that's entirely the fault of the Working
Group and doesn't reflect *at all* upon this list. I've asked you here to
provide a rich set of advice so that the product that the Working Group
produces can be the best possible product but don't think that I'm explicitly
or implicitly asking any one to provide more help than answering questions and
providing an experienced conversation. If people on here would like to help
with the product creation half, let me know I'll add you to the working group
and we'll start figuring out what you can do from the *other* half of this
task list.

> Adam K
>
> (Apologies if joining mid-thread has got me talking at cross-purposes)

You've generated some though and forced me to look at history to make sure
we're not doomed to repeat it. That's always worth doing.

-Chris

[1]: Production here can include paid development for a customer / client.