From c.nehren/ec at shadowcat.co.uk  Thu Aug 26 08:09:55 2010
From: c.nehren/ec at shadowcat.co.uk (Chris Nehren)
Date: Thu Aug 26 08:10:04 2010
Subject: [Epo-extended-core] Is it time for a perl-ec?
Message-ID: <2513F88F-492C-4ED8-8B47-B097B28F6627@shadowcat.co.uk>

I talked briefly with perigrin in #epo-ec tonight about possibly putting together a distribution of perl that includes the Extended Core (presently in the form of Task::Kensho, of course). Right now I'm thinking about putting the effort into evaluating whether this is feasible on a technical level, and proceeding from there in the event I'm successful. I'd like wider input on this before continuing. Here's a transcript of the IRC conversation and some notes I've written up:

<apeiron> Also, I've come up with this crazy idea inspired by someone asking in freenode's #perl about how to bundle a M::I dist with perl.
<apeiron> I'm wondering about working on putting together a preview of perl-ec.
<apeiron> as in, something that will install perl and then the Task::Kensho stuff.
<perigrin> go for it
<apeiron> You don't think it's too soon?
<perigrin> it has been only 3 years
<perigrin> you could be right
<perigrin> :p
<apeiron> hmm, indeed. 
<apeiron> okay, then.  
<perigrin> 43 releases ...
<apeiron> The thing is, if we're going to do this, we need to do it *perfectly* from the start, or as near as we can, or downstream vendors won't adopt it.
 * perigrin nods
<perigrin> the monthly releases I think will help downstream adoption
<perigrin> this is why I started that 
<perigrin> adding in a deprecation policy
<apeiron> hmm, actually, I'm wondering if a freeze would help perfect it.
<perigrin> and an official application policy
<perigrin> it's what I tried starting with EPO-EC
<perigrin> but that didn't go far fast
<apeiron> nod
<perigrin> it's easier if *someone* makes a decision
<perigrin> with a clear policy on how to revert the decision
<perigrin> rather than trying to achieve some kind of cohesion first
<apeiron> I'm fine with doing that. I'm just not sure if I'm going to be *right*.
<perigrin> well that's why you establish a policy to say "fuck that was wrong, in six months it'll be fixed"
<perigrin> Honestly 
<perigrin> I wouldn't target downstream vendors yet
<perigrin> not until we can build some kind of momentum to make sure we get patches for the modules etc.
<apeiron> Fair enough.
<perigrin> it may be a bit soon for the *official* EPO-EC
<perigrin> but for a Disk::Kensho
<perigrin> er Dist 
<perigrin> I think it's a perfect time to work out the crazy "could we make a dist from this" stuff
<apeiron> hmm, yeah, I suppose it's still too soon for an official EPO-EC.
<apeiron> There's relatively scant email support still.
<perigrin> and we have no support network for making sure that Task::Kensho modules are supported
<perigrin> I mean I know between SC and Tamarou we could offer real support contracts :)
<apeiron> nod
<apeiron> I'm not in a position to offer such, but I don't think mst / mdk would oppose.
<perigrin> I'm sure they'd be up for it. 
<apeiron> Your collection of contractors is probably a good start for commercial support.
<apeiron> And I do definitely recognize the importance of commercial support.
<apeiron> It'd need to be mentioned, prominently.
<perigrin> yes
<apeiron> e.g. a top-level file in the source kit and a doc like perlsupport.
<apeiron> apt-get install perl-ec # I rather like this
<perigrin> :)
<apeiron> hmm
<apeiron> As it's perl-ec, perl itself is part of it. So we can ship whichever version we wnat.
<perigrin> I'm being told it's bed time 
<apeiron> heh, okay.

And the thoughts I've had on the matter (admittedly a rough outline that I can expound upon given more than a few hours late in the evening for me):

* monthly releases help adoption
    * predictability is important for businesses
    * need to develop adoption / deprecation policies
    * clear policy for "oh shit I fucked up" fixes
* support
    * we need commercial support. it is not an option.
    * need to talk to enlightened consultancies to get them on board
    * this whole effort is a wash without commercial support
    * support needs to be prominently documented and available
    * web presence
    * possibly include or link to the whitepapers on 
      http://www.perl.org/about/whitepapers/
    * we want to appeal to the suits. learn from languages that do this
      well (Java).
* policies
    * whatever we do, we need to tie in with the EPO
        * give businesses a voice
        * much open source work is sponsored by businesses
        * give businesses a support recourse: if something they depend
          on is voted out, support contracts need to be available to
          keep it working or move them to something viable
    * one way to do it: RFCs
        * works well for mature languages (java, python) and
          communities (apache--though they've got lots of bureaucracy)
        * vote things in / out
    * lots of wisdom at http://lists.scsys.co.uk/pipermail/epo-ec-advisors/2009-July/thread.html
* perl-ec itself
    * composable
        * not everyone cares about mysql
        * not everyone cares about catalyst
        * etc.
    * robust
        * deps scanning. tested on everything from cooking oil to
          rocket fuel. we already have much of this with the existing
          cpants infrastructure.
        * support a goddamned uninstall target
    * automated
        * scriptable. no admin wants to sit and babysit a package for
          hours while it installs, unless his name is Wally.

-- 
Thanks and best regards,
Chris Nehren