[Catalyst] using catalyst as a developer

[David Rio Deiros]

Yuval,

Thanks for your answer it was very helpful.

One question though. What do you mean when you talk about unit tests?:

Thanks,

David

On Tue, Mar 21, 2006 at 10:05:57AM +0200, Yuval Kogman wrote:
> On Mon, Mar 20, 2006 at 23:48:12 -0800, David Rio Deiros wrote:
> > Hi there,
> > 
> > I would like to know how catalyst developers work with the sources
> > in order to improve/patch/fix catalyst.
> 
> Yay!
> 
> > 2. checkout catalyst repository in one of the @INC perl directories.
> 
> Nope. The tree is distribution oriented, so it doesn't really match
> @INC...
> 
> What I do is install the plugins I don't develop, and for the ones I
> do (Catalyst itself, sessions, authentication, etc) i have a simple
> alias in my .profile
> 
> 	alias catlib='export PERL5LIB=`ls -d /Users/nothingmuch/Perl/catalyst/{Catalyst,*Auth*,*Session*,*Log*,*HTML-Widget*,*BindLex*,*Workflow*,*Stack*}/lib | tr \\\\n :`'
> 
> I could make this static but I sometimes want to use installed
> modules over existing ones.
> 
> Ingy has a small script to generate an @INC valid dir out of a
> dist-tree using symlinks... I'll ask him to post it.
> 
> > 3. create a test catalyst application that uses the feature you are working
> >    on.
> 
> Yes, and make sure that this can be converted to unit tests or
> TestApp code later.
> 
> > 4. patch/modify code
> > 5. reload application
> 
> foo_server.pl -R might do this if i'm really desparate. I always
> wanted it to respond to changes in all of keys %INC with some
> special flag.
> 
> > 6. test new feature
> 
> Not enough - functionality testing is only half the story. Write
> real unit tests.
> 
> > 7. generate patch and submit to the mailing list/ #catalyst for revision
> > 8. if patch approved it and you have commit privileges, commit changes
> 
> If it's a small patch and you're sure of yourself, you can just
> commit it.
> 
> Otherwise ask on #catalyst.
> 
> Remember that this is revision control and changes can be undone
> easily. If it seems like a right thing to do and nobody violently
> disagrees then worst case scenario someone will revert it later.
> 
> If it's a medium patch, ask catalyst-dev people.
> 
> If it's a big patch there's the 3 dev rule - at least 3
> catalyst-dev members must agree that it's a good thing before it's
> comitted.
> 
> Also, mst's general rule for who gets commit: if you're working on
> it and you've shown that you're sane based on unidiffs, then you get
> access.
> 
> 
> A slight digression: we've discussed the issue of future directions
> of Catalyst, and hopefully we will have a simple road map that will
> help clarify the type of code we want, like what is high priority,
> etc. The general idea is that we want to refactor some things that
> don't need to be core, and get stability improvements. Bigger
> changes will need to be more thoroughly discussed.
> 
> I hope sri gets well soon and publishes this roadmap thing ;-)
> 
> -- 
>  ()  Yuval Kogman <nothingmuch at woobling.org> 0xEBD27418  perl hacker &
>  /\  kung foo master: /me wields bonsai kittens: neeyah!!!!!!!!!!!!!!!!
> 



> _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst


-- 
Laws of Serendipity:
        (1) In order to discover anything, you must be looking for something.
        (2) If you wish to make an improved product, you must already
            be engaged in making an inferior one.