Re: [zeta-dev] Migration from Make to Ant
Hi, I should leave some last words about this, which I hope clarify the base of the issues Gavin and Derick have. I recently tried to help Jerome via Jabber to get the website build script to run on his Mac. We failed on many of the inconsistencies between shell commands on the two systems (e.g. cp) and the quick solution was to replace the current make file with something else. Since we both knew ant and since ant is widely used, this sounded like the perfect solution for a quick migration to solve our problem. There was no intention to silently replace the current Makefile with ant and go with it in the future. I'm sorry that it appeared to some people that way, here on the list. I can understand Derick to be upset, if he interpreted it like this. Anyway, as Julien pointed out, we should find a consensus on a build system which we all support. And as I recently discovered, this should be a well thought out thing, since we should stay with a single system for all build stuff (e.g. release management, CI, etc). So, let's move on and see the website thingies as a proofs of concepts for a build system. Cheers, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
[zeta-dev] Update on the wiki
Hi, I finally found some time to investigate on the wiki some more. As it turned out, Confluence is not capable of handling the scenario we discussed a while ago here. :( Therefore I suggest to only use the wiki for internal purposes for now. As a first step I create an RFC section where we can keep track of important and long-going discussions (like the current one on a build system). Jerome will try this out here: https://cwiki.apache.org/confluence/display/ZETACOMP/Build+system By now, only the group zetacomponents-committers has write access to the wiki. I currently desire to add a zetacomponents-developers group and to permit write access to it, so we can have any member of this list contributing. Please speak up, if you disagree. Cheers, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Proposal: Commit guidelines
On 04/08/2011 11:25 PM, Gav... wrote: This whole thread started because the 'actual standards' state to only mention the Issue Number in the final commit... ...+However, larger features or bug fixes, should be split them into +smaller commits. In this case, the issue number should only occur in +the final commit, which closes the issue... As mentioned before, knowing which is really the last commit to close an issue is a hard one, and having many commits not tied to an issue number makes people wonder what issue it is for. Jira itself keeps track of commits for a particular issue, but only if the commit has the issue number mentioned in the commit message. See for example: https://issues.apache.org/jira/browse/ZETACOMP-8?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel#issue-tabs and most other projects are doing the same thing, i.e. https://issues.apache.org/jira/browse/FOR-1224?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel#issue-tabs https://issues.apache.org/jira/browse/TS-516?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel#issue-tabs etc etc... for that helpful feature alone it is worth the extra few characters per commit message. I agree with Gavin that this would indeed be useful. However, we should try to not end up with endless infrastructure discussions. :) What is desired here is a simple way of mentioning the issue number in each commit where we work on a specific issue. What about: - Fixed #ZETACOMP-$x: ... for the final commit fixing an issue and - Work #ZETACOMP-$x: ... for intermediate commits? The Work keyword can then be used for both, issues and enhancements, we don't add much bloat and stick to the current way of having simple keywords. Regards, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
[zeta-dev] Build system evaluation
Hi, I feel the need to start this new thread in order to coordinately evaluate a build system to be used in Zeta, since the discussions are quite wide spread currently and we should maybe reboot it in order to get something can all agree upon and live with in the future. In addition to this discussion I very much appreciate if Jerome continues his efforts to realize our website build script with different build tools, so we get real live impressions of what they are capable of. What especially concerns me is that we should decide on a single system for all future tasks where we might need a build system, too, not only for generating the website. For example the release process and everything around (tagging releases, running tests up-front) should be implemented as a build script, as well as CI related tasks. I'd suggest to extend Jeromes evaluation in this direction. In order to support it, I have created a first wiki page [1], where Jerome will keep a summary of the evaluation and develop it further. To make one thing clear up front: Nobody has to use the wiki or even read it. The page is by now just there to keep track of the summary state of the discussion so you don't need to read the full threads to get into it. To reboot the discussion, I'd recommend to start with requirements we have for a build system. From my POV: - Portability - scripts should run on all common systems - devs should not care much about OS issues - Extensibility - be able realize even unusual tasks - build reusable stuff with it - Maintainability - modular tasks and dependencies - devs should feel comfortable - easy to read build files - Integrability - should work with CI systems (esp. Bamboo, maybe Jenkins) I would also love if the system we choose gives us a wide range of pre-built tools at hand, which are common for build tasks (e.g. working with file lists, creating/extracting archives, property management, etc.), but this could also be built by ourselves, if necessary. Let the fight continue. :) Regards, Toby [1] https://cwiki.apache.org/confluence/display/ZETACOMP/Build+system -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] PHP based build system : Phing VS Pake
Hi Alexey, thanks for your feedback. On Wed, Apr 13, 2011 at 10:40 PM, Alexey Zakhlestin indey...@gmail.com wrote: [...] Any feedback welcome :) line 30: I'd use pake_echo_comment() instead. same for other similar lines Fixed. lines 94-117: 1) I'd use pake_sh($command, true) Fixed. 2) don't forget to use escapeshellarg() where appropriate Yep, I will take care of that later. lines 134-137: pake_mkdirs($targetDir, 0755); // no need for if. pake take cares of that Fixed lines 139-149: pake_copy($tarball, $targetDir.'/'.$options['build.name'].'.tar.bz2'); Fixed lines 142-143: pake_remove_dir($options['build.dir'] . '/phpdoc/'); Fixed lines 243-245: pake_rename( $HTMLFile, dirname( $HTMLFile ) . '/' . $newHTMLFile ); Fixed pake's versions of basic filesystem-functions are good because: 1) they do nothing, if nothing has to be done (won't try to delete non-existant file, won't copy file if source is older than target) 2) they report what they do to console as the result, you have to type less code Yep that is what I noticed, and that gave me a couple of ideas to enhance ezcBaseFile Thanks :)
