[Epo-extended-core] Is it time for a perl-ec?
Chris Nehren
c.nehren/ec at shadowcat.co.uk
Thu Aug 26 08:09:55 GMT 2010
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
More information about the Epo-extended-core
mailing list