ACT - Voyager - logbook 2014-09-01
- people that want a complete rewrite
- people that want a quick fix and new features on top of the current ACT
- people that want to change the internals first
Doing a total rewrite, as usually, was being advised against, but has some challenging aspects. Making it possible to start hacking on the current version of ACT has the advantage that things can start immediately... although there has been proposed to make the current Apache1/ModPerl version of ACT run inside a PSGI environment. Haarg has previously made a PSGI port (3 years ago), which has not yet been merged back, due to deployment changes required for current live setup. SawyerX is working on a revised approach which may not need this. Once one of these solutions is merged in, it will be possible to hack on the current version at two different fronts: add features and hack the core in the meantime.
We are looking forward to see what Sawyer is doing for some kind of wizardry.
Thank you Todd Rinaldo for setting up a new ACT repository at GitHub and creating the teams and send out the invitations.
During Lunch with BooK I was very happy to hear how he sees how this ACT Voyager project will work in conjunction with the current ACT repository at GitHub and the servers.
BooK suggested that whenever the Voyager team does a pull request on the original BooK/ACT repository, it will be checked out at the ACT test server to see how the changes will effect in real life situations. From there, it will go to the real ACT server. This cycle should be done as quick and frequent as possible after the pull-request. This way, the effort people take to work on the new repository will show up in production soon and it will not slow down the project.
One thing that BooK suggested will certainly help in moving forward more quickly: some discipline for all those that want to hack on the old code! Once the DBIx::Class schema is functional and working, there is still code in the ACT::Core that needs to be updated. All developers that want to add or edit features in the old version that rely on modules in the core, should first fix all the methods in core before adding on top off it... and test, test test. Once that stage has passed and committed (and merged) hacking on the features itself can start. This way, we make developers more responsible and involved in the whole project.
Later this year, BooK will organise a hackathon in Lyon. Salve J. Nilsen has already scheduled the hackathon in Oslo in May next year.
I am very grateful for all the support I get from people more intelligent than I am and specialised in important technologies that ACT will be build on.
Theo van Hoesel