- dancer-users - lists.preshweb.co.uk

Dev and Release workflow ( was: Re: Invalid value for log config )
by damien krotkine 20 Dec '10

20 Dec '10

*top-posting* OK here is a first version of my opinion. You may not like it :) I'm playing a bit of devil's advocate too. We are talking about Dancer : a cool project that is very easy to use, to start with, and to build your web platform on. I suggest we try to have the same goal for the development and release environment. So there should be no thinking needed when getting a production release on CPAN, and there should be freedom to hack Dancer code 1/ About CPAN releases : I don't think it's useful to have even and odd releases visible for user (aka on CPAN). Either you have something stable you are happy to ship for production use, and you ship it on CPAN, or you don't ship it at all. Having multiple versions on CPAN with odd numbers, etc, will make it more difficult for users to know which one is good for them. Especially because we don't have strict deadlines. So basically, you may end up in 2014 having 1.4 good and stable since feb 2011 but with an old set of features, and 1.5 containing a bunch of new features, but considered unstable. Basically that's the debian approach (*ouch* don't *ouch* hit me! ), and release management and cycles will become a nightmare. So I'm in favor for 1.2 and 1.3 being both stable versions. And only these to be released on CPAN. 2/ About github : The problems we have currently is that : - the dev manager (sawyer for now I think - congrats) has to choose what to pick up from developers branches. He has to handle conflicts, test failing and so on, if the branch has been made long time ago - the developer is frustrated because he doesn't see his code merged in devel before long ( he's being said "after we release 1.2", "after advent calendar", "after we have talked about it", etc) To fix these issues, I propose that we keep devel and master as we have them, but add a new *experimental* branch. It's a big open sandbox : - this experimental branch is recreated from devel each time a new stable version is done, or when the dev manager thinks it's too messy - Dancer developers are trusted : they can push new branches and *merge* them into experimental, as long as they don't use rebase, and that the test suite passes - the dev manager picks up branches he likes from the experimental branch When new versions are released, the sandbox is cleaned up, experimental branch is wiped out and recreated from devel, and a next cycle can occur. Benefits : - developers can see their work in action in the code. Other dev will get the features immediately, they will react quickly : either they like it, or they don't, so they argue with the developer that merged the change. But they are not frustrated anymore - dev manager has less work to do regarding conflicts and merge issues, because developers take care of test passing when they merge - dev manager has an easy way to clean up things : wipe out experimental and recreate it Because we use git, developers don't loose their work when experimental is wiped out : they have their own branches. All they have to do is to rebase them on the new experimental branch, and fix tests / conflicts if any. This way of doing is from a simplified version of previous work experience. Just my 2 cents, may be useful for the discussion. Remember, developers freedom is important :) On 17 December 2010 11:10, Alexis Sukrieh <sukria(a)sukria.net> wrote: > Le 16/12/2010 20:16, sawyer x a écrit : > > Our deprecation policy is to warn of deprecated behavior in the current >> release version in which it was deprecated (1.2x, 1.3x, whatever), and >> die fatally in a following major release. >> > > Indeed. > > > This could be added in Dancer 1.3x, including the deprecation warning. >> Then removed entirely in 1.4x. >> > > I agree, using the 1.3 releases serie for deprecating stuf inn 1.2 sounds > good. Making them fatal error in 1.4 makes sense. > > This strategy sounds good: release series with even number (1.2, 1.4, 1.6, > ...) always contain stable features, intermediate series can deprecate > things in the previous serie (1.3 can deprecate, with warnings, stuff in > 1.2). > > I like that. > > > 1,2x was released only recently, so I'm not sure if we already want to >> deprecate stuff for the big chunk of users we now added (thanks to many >> marketing efforts by the entire community). >> > > As explained, I'd rather never deprecate anything in a stable serie, 1.2xxx > is meant to provide bugfixes, documentation updates to the 1.2000 release, > only. New features should be added to 1.3xxx in my opinion. And this is > where deprecation can occur. > > So: > > 1.2xxx => stable codebase, no deprecation, no new features > 1.3xxx => development codebase, deprecation, new features > > I welcome your points of view on this strategy. > > This also reminds me we need a new permanent branch on the repo, like > experiemntal, where we will build releases for 1.3 > > I use such a layout at work, and it works pretty well (with git-flow > configured in two different ways): > > 2.0000 > -[ master ]------------------------------|-----------------------> > > -[ devel ]--+----------------------------+----------------------> > \ / > \-[ topic/XXXXX ]--------/ > > > This layout is good for maintaining one release cycle, but if we want to > provide development releases in parallel (1.3xxx) we need one more branch. > Otherwise it will be veru difficult to maintain the 1.2 serie. > > So the layout could become somthing like this: > > > 2.0000 > -[ rel-stable ]-----------------------|-----------------------> > > -[ dev-stable ]--+----------------------------+----------------------> > \ / > \-[ topic/XXXXX ]--------/ > > 2.000 ... 3.0001 > -[ rel-unstable ]-----------------|------------|-----------> > > -[ dev-unstable ]--+----------------------------+----------------------> > \ / > \-[ topic/XXXXX ]--------/ > > > The rel- branches are used by git-flow to produce releases, the dev- ones > are used as integration branches. > > My main concer is how can we publish those releases on CPAN... > > > >> Either way, there's no reason why not to start using this structure >> manually and implement the new strictures in a new branch to be merged >> on whichever release in which we want it. I'll try to get on it sometime >> soon. >> > > Yes, that's another way of doing it, maybe more simple: use some parallel > branches and merge them when we want, but I fear this will become very hard > to maintain over time, if we want 1.2xxx to remain stable. > > Feel free to coment on that idea. > > Regards > > -- > Alexis Sukrieh > > _______________________________________________ > Dancer-users mailing list > Dancer-users(a)perldancer.org > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >

4 7

Getting auto_reload to work
by Deepak Gulati 19 Dec '10

19 Dec '10

Hi Folks, I am trying to get my dancer app to restart/reload any time I change a module in my lib directory. I've set auto_reload to 1 in config.yml and have Module::Refresh and Clone modules installed but nothing seems to happen when I make a change to a module in the lib folder and I have to manually restart for my changes to take effect. I am on Perl 5.10.1 and Dancer 1.2002 running on Mac OS 10.6.5. What am I doing wrong? I realize that auto_reload isn't meant for production use, but it'd be nice to have my changes loaded automatically on my dev box. Thanks, Deepak

8 13

Known problems with Open3?
by ambs 19 Dec '10

19 Dec '10

Hello I am still in debug mode, but does anybody had any problem with open3 when running the standalone server? It seems that STDOUT is getting linked somehow to the terminal window where app.pl is being run. More details as I find them :) Cheers ambs

2 5

dancer websockets tutorial
by Naveed Massjouni 19 Dec '10

19 Dec '10

So I finally got time wrap my head around Franck's chat demo that uses websockets. I was thinking about making a tutorial for creating websocket apps using dancer. And including it in the dancer docs somewhere like lib/Dancer/WebSocketTutorial.pod. Do you guys think this makes sense and would be useful? -Naveed

5 5

Re: [Dancer-users] Known problems with Open3?
by ambs 18 Dec '10

18 Dec '10

On 18/12/2010 20:40, sebastian de castelberg wrote: >>>> I am still in debug mode, but does anybody had any problem with open3 >>>> when running the standalone server? >>>> >>>> It seems that STDOUT is getting linked somehow to the terminal window >>>> where app.pl is being run. >>> >>> For those wanting to help me debug, here is a teste case: >>> >>> http://paste.perldancer.org/1oRJn4LgYzcfV >>> >>> Not sure if this is open3 fault, or Plack/Dancer that is changing >>> something it shouldn't... >> >> Seems an open3 bug: http://rt.perl.org/rt3/Ticket/Display.html?id=66224 > > Save and reset STDOUT is a workaround. > http://paste.perldancer.org/EZUg9A5NVEv5 Hmms, thanks. Now the script is crashing a little ahead with a broken pipe when writing to that filehandle... Let see if I can debug it... Thanks, again :) Alberto

1 0

Deploying with fcgid under a specific directory
by ambs 18 Dec '10

18 Dec '10

Hello I am deploying dancer in a directory, like http://server/query instead the root path. This is my redirect configuration: RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^/query(.*)$ /query/dispatch.fcgi$1 [QSA,L] While the main page works, when I use <% request.base %>file in a template, it gets http://server/queryfile I tried to solve this, using <% request.base %>/file, but then it gets as http://server//file when testing with bin/app.pl What am I doing wrong? Also, when using "redirect /" in Dancer code, should I use "redirect /query" instead? Or "redirect request->{base}" ? Thank you ambs

1 2

Error log with fcgid
by ambs 18 Dec '10

18 Dec '10

Hello Where should I find errors when running Dancer with fcgid? my logs/ log files are all empty :( Thank you ambs

2 1

Selectively calling before() from route handlers
by Gurunandan Bhat 17 Dec '10

17 Dec '10

Hi, Is there a way I can set whether a particular route handler calls before(). I am looking to implement authenticated/unauthenticated routes and would like to execute before() only if the route requires authentication. Any suggestions in doing something like this would be great. Thanks.

3 3

Reverse-proxy deployments
by Flavio Poletti 17 Dec '10

17 Dec '10

Hi All, just a thought about the reverse-proxy deployment strategy and how you handle it. First of all, it seems that this approach "burns away" the uri_for function, because it insists on working upon the "internal" URI and not the one seen on the external side. I worked this around by re-defining uri_for and forcing the usage of a configurable base URI, but I'd like to hear whether there is a better/standard/builtin alternative to this. Looking at the code it does not seem that the current implementation of uri_for is ready for a reverse-proxy envinroment, maybe this could be provided as a generalisation of the current uri_for? Maybe with some Dancer::Plugin::ReverseProxy plugin? Another thing has to do with the static contents. By default this lives in the same "space" as all the routes, although in separate subdirectories. To serve this content statically, it means that each item in the "public" directory within my app tree must be explicitly dealt with by the reverse-proxy server with an ad-hoc configuration, e.g. in Apache I would put: ProxyPass /path/to/app/css/ ! ProxyPass /path/to/app/javascripts/ ! ProxyPass /path/to/app/images/ ! ProxyPass /path/to/app/favicon.ico ! ProxyPass /path/to/app/ http://www.example.com/killer-app/ ProxyPassReverse /path/to/app/ http://www.example.com/killer-app/ This might be annoying and error-prone: what if I add another directory/item and I forget to change the configuration of the proxy? In this case, the safer approach seems to be the configuration of a "static" directory inside the reverse proxy, which is accessed through http://www.example.com/path/to/app/static/, but this in turn means that the templates have to be modified to include this new "static" subdirectory. This approach is not the default one while creating a new Dancer app, so I'd like if someone can share some thoughts about possible alternatives to this kind of modifications. Thank you, Flavio.

3 4

Keeping values on a form
by ambs 17 Dec '10

17 Dec '10

Hi This is not really a Dancer problem, but something that I am missing when changing from CGI to Dancer + TemplateToolkit. Basically: - I have a form with an array of checkboxes - that form gets submitted - some results are shown, together with the form for resubmission The question is, how do I keep the checkboxes checked (or not) accordingly with what the user picked before submitting it? For reference, CGI called this behavior as stiky: By default the CGI module implements a state-preserving behavior called "sticky" fields. The way this works is that if you are regenerating a form, the methods that generate the form field values will interrogate param() to see if similarly-named parameters are present in the query string. If they find a like-named parameter, they will use it to set their default values. Thank you ambs

4 7