[Catalyst-dev] Status, stuff and nonsense (change this subject when you reply)

[Matt S Trout]

I'm losing track a bit of where we're up to due to the amount of 
(generally cool) stuff going on. So I'm going to outline where I think 
we're up to, and I'd like the rest of you to correct me and fill in the 
blanks where appropriate.

Monju branch: (nothingmuch)

No idea where this one is. Care to enlighten us?

Moose branch: (marcus, mostly)

This branch has ended up being a bit of a mish-mash since it was the 
only one for a bit. If I got what marcus said to me right, I think his 
current plan (which I'm in favour of - shout out if you aren't) is to 
split what's in there into three

(1) Doc stuff - most of this can be extracted and committed to trunk
(2) Log stuff - not sure whether this is worth a branch or should go 
striaght into trunk
(3) Moose stuff - very cool but needs to settle a bit. Also needs some 
heavy kicking for performance and bugs
(4) Action stuff - ace interface design as always by the now-lost sri, 
implementation is fine but again needs performance and bug kicking

Basically, if we extract the commits for (1) and (2) and chuck 'em back 
into trunk (jester, ghenry, castaway, fancy tracking and helping with 
this?) and somebody who groks it (probably marcus) sorts out the log 
stuff, we can pull back down to branch to make sure those are merged 
correctly, then when we get to the point where (3) and (4) are ready we 
can dev release 'em, beat 'em up, and look at merging back to trunk once 
it's stable.

Only trouble is the revision history is already pretty screwed on there, 
so I suspect we're going to have to commit the Moose/Action stuff back 
to trunk as one almighty patchset. This is a bit sad, but livable, and 
if nobody else has any better ideas I say we go for it when the time comes.

Docs branch: jester, ghenry?, castaway?, hkclark?

There's a long-overdue doc/tutorial rework/etc. that's been bubbling 
through the planning stages on IRC for a while. I reckon we should 
probably start a docs branch for it so the people with the "explaining 
shit in plain english" chops have somewhere to play without people like 
me getting in the way. If you lot are in favour of it, kick me to set it 
up and make sure the svn permissions are right.

Module::Pluggable::Fast removal and setup_components refactor (mst)

I know I'm forever harping on about this, but it'd buy us a few good 
things - (1) no dependence on a woefully untested, fast-hack-code 
module, (2) easier overriding and extending of the setup process, (3) 
*finally* a way to get rid of editor dot files and stuff out of the 
loaded components list.

I know a few of you have been asking for (3), so I expect volunteers to 
come forward to help with this (esp. to thoroughly test it since it's 
such a critical method), though I'm willing to do at least some of the 
heavy lifting. We'll discuss implementation details later; right now I 
just want to know available manpower and if anybody else cares :)

Application/Context split

I want this. I really, badly want this. But I say punt for the moment 
since we've got enough on our plate. Once Moose/Action goes to trunk 
though we should revisit it ASAP.

=======================================

Ok, I'm done rambling. Rest of the core team, get your thinking caps on, 
I expect all of you to pitch in and reply with useful comments - 
preferably more useful than my randomised screed above.

Anybody replying to this, I'd really like it if you replied to *one* 
section of the above per message and changed the subject line to 
indicate which one as you do (even consider making it a separate thread 
if you feel so inclined), this conversation is likely to get complicated 
and if we lose track it loses its point.

And now I'm really done. Enjoy.