Re: Renaming the Apache Zeta Components
We have to drop the Apache. We are currently in discussion with tradema...@lists.apache.org about being allowed to reuse Zeta Components or Zeta - which at the moment seems possible. greetings, Benjamin On Tue, May 15, 2012 at 1:40 PM, Maxime Thomas maxime.t...@gmail.comwrote: Hi there, Apparently, we have to rename the Apache Zeta Components due to Apache trademarks. A natural name could be Zeta Components but I'm not sure we're still allowed to name it like this. I didn't find any information in http://www.apache.org/foundation/marks/faq/#products. Do you have some other ideas ? -- Maxime maxime.tho...@wascou.org | www.wascou.org | http://twitter.com/wascou
Re: Migrating Zeta Componetns to Github
@Christian So are there any news? On Wed, Apr 25, 2012 at 2:00 AM, Benjamin Eberlei kont...@beberlei.dewrote: Hello everyone, i have just completed the migration of the Apache SVN to Github organization: Code is still pushed at the moment, these are the done tasks: https://github.com/zetacomponents * Each component is split into its own repository * Author Information has been updated on frequent committers i have found the email of (or could asked for). * composer.json was added to every project. No dependencies were defined on other components (even though could be done through DEPS) - because the Base version was never specified and such the information is incomplete anyways. Releases in the future should go and specify the dependencies of packages more explicitly. * All tags have been generated from the commit messages. * MVCTools Migration didnt work, I have to try this again. * Document has some problem with GC and is very large repo, i have to cleanup or remigrate so i didnt push to github yet. However code is not yet free for changes, we have some problems to tackle: * Do we need to adjust the headers? If yes, we should do this now using a mass-edit. Do we have to clear this with Apache legal? * Unit-tests have still to be fixed, we need a generic approach for all components for that. * I fixed the Archive component as an example: https://github.com/zetacomponents/Archive/commit/541b1faca6d63c441bead83fe8ca5d9e174afe53 Then just composer install --dev phpunit from the root of the Archive component. * All packages have to be put on packagist.org so can be used with Composer. greetings, Benjamin On Fri, Apr 20, 2012 at 1:35 PM, Benjamin Eberlei kont...@beberlei.dewrote: Repost into its own topic for better seperation: I volunteered to do a migration of the code to github. I will do the following steps: 1. Do a SVN to Git migration for every component on its own. Every component will have its own repository with issue tracker on Github. 2. Rewrite history to add composer.json files to all stable tags 3. Push to Github Derick already opened an Organization on Github and I guess all current committers will get write access to it. Adding composer helps us with the deployment issue in the short term and in the medium/long term we could maybe setup a pirum channel on github pages to enable PEAR installation again. Composer can work with classmaps so that the file/class layout is no problem for autoloading and components become instantly usable by third parties. The next step would then be that committers claim components and we determine the deprecated/abandoned/ maintained state of each of them. Every maintainer is then responsible for getting the tests back running with the new schema and adding this to travis-ci. I will attempt to do this for one component as a demonstration. I can't give a timeframe on this but will highly prioritize this and hope to get it done within a week. greetings, Benjamin
Re: [call for review] Keeping the eZ Publish Community in the loop
The naming is completely undecided yet, we have contacted apache trademarks, since we don't know how to proceed. Also i agree with julien, the inactivity was the major reason to retire from ASF, since we couldnt follow procedure with quarterly reports anymore due to lack of time and didnt manage to get a first release under Apache flag out. The seperation of components into their own repositories are also done to seperate the maintained from the unmaintained ones more easily :-) On Thu, Apr 26, 2012 at 1:56 PM, Julien Vermillard jvermill...@gmail.comwrote: Hi, Even if I think it's a good idea to keep the community in the loop I would like to remeber two points : - the zeta podling retirement vote was start due to lack of progress - if you want to use the Apache/ASF word you need to contact the Apache PR for that Julien On Thu, Apr 26, 2012 at 11:35 AM, Nicolas Pastorino n...@ez.no wrote: Dear everyone, I thought it would be wise to keep the eZ Publish Community in the loop, since they are likely to be the largest share of AZC users today. Here is a small blog-post, on which I would love to have your input : https://docs.google.com/a/ez.no/document/d/1SLuBI6HQqX_PJnswCOaV6MyW2AbOd0-1wTDwhHIf3f4/edit (anyone should be able to edit it, or make remarks through comments). I hope this fits you well and I am looking forward to your feedback ! -- Nicolas
Re: [call for review] Keeping the eZ Publish Community in the loop
@Christian thats good to know, i don't get mails back from the list i sent the naming question too. Its probably summed up and sent back to this list when final decision is made? On Thu, Apr 26, 2012 at 9:28 PM, Christian Grobmeier grobme...@gmail.comwrote: On Thu, Apr 26, 2012 at 9:21 PM, Benjamin Eberlei kont...@beberlei.de wrote: The naming is completely undecided yet, we have contacted apache trademarks, since we don't know how to proceed. I can confirm this has made its way into some private mailinglists and people are discussing it already. Cheers Also i agree with julien, the inactivity was the major reason to retire from ASF, since we couldnt follow procedure with quarterly reports anymore due to lack of time and didnt manage to get a first release under Apache flag out. The seperation of components into their own repositories are also done to seperate the maintained from the unmaintained ones more easily :-) On Thu, Apr 26, 2012 at 1:56 PM, Julien Vermillard jvermill...@gmail.comwrote: Hi, Even if I think it's a good idea to keep the community in the loop I would like to remeber two points : - the zeta podling retirement vote was start due to lack of progress - if you want to use the Apache/ASF word you need to contact the Apache PR for that Julien On Thu, Apr 26, 2012 at 11:35 AM, Nicolas Pastorino n...@ez.no wrote: Dear everyone, I thought it would be wise to keep the eZ Publish Community in the loop, since they are likely to be the largest share of AZC users today. Here is a small blog-post, on which I would love to have your input : https://docs.google.com/a/ez.no/document/d/1SLuBI6HQqX_PJnswCOaV6MyW2AbOd0-1wTDwhHIf3f4/edit (anyone should be able to edit it, or make remarks through comments). I hope this fits you well and I am looking forward to your feedback ! -- Nicolas -- http://www.grobmeier.de https://www.timeandbill.de
Re: Migrating Zeta Componetns to Github
Hello everyone, i have just completed the migration of the Apache SVN to Github organization: Code is still pushed at the moment, these are the done tasks: https://github.com/zetacomponents * Each component is split into its own repository * Author Information has been updated on frequent committers i have found the email of (or could asked for). * composer.json was added to every project. No dependencies were defined on other components (even though could be done through DEPS) - because the Base version was never specified and such the information is incomplete anyways. Releases in the future should go and specify the dependencies of packages more explicitly. * All tags have been generated from the commit messages. * MVCTools Migration didnt work, I have to try this again. * Document has some problem with GC and is very large repo, i have to cleanup or remigrate so i didnt push to github yet. However code is not yet free for changes, we have some problems to tackle: * Do we need to adjust the headers? If yes, we should do this now using a mass-edit. Do we have to clear this with Apache legal? * Unit-tests have still to be fixed, we need a generic approach for all components for that. * I fixed the Archive component as an example: https://github.com/zetacomponents/Archive/commit/541b1faca6d63c441bead83fe8ca5d9e174afe53 Then just composer install --dev phpunit from the root of the Archive component. * All packages have to be put on packagist.org so can be used with Composer. greetings, Benjamin On Fri, Apr 20, 2012 at 1:35 PM, Benjamin Eberlei kont...@beberlei.dewrote: Repost into its own topic for better seperation: I volunteered to do a migration of the code to github. I will do the following steps: 1. Do a SVN to Git migration for every component on its own. Every component will have its own repository with issue tracker on Github. 2. Rewrite history to add composer.json files to all stable tags 3. Push to Github Derick already opened an Organization on Github and I guess all current committers will get write access to it. Adding composer helps us with the deployment issue in the short term and in the medium/long term we could maybe setup a pirum channel on github pages to enable PEAR installation again. Composer can work with classmaps so that the file/class layout is no problem for autoloading and components become instantly usable by third parties. The next step would then be that committers claim components and we determine the deprecated/abandoned/ maintained state of each of them. Every maintainer is then responsible for getting the tests back running with the new schema and adding this to travis-ci. I will attempt to do this for one component as a demonstration. I can't give a timeframe on this but will highly prioritize this and hope to get it done within a week. greetings, Benjamin
Re: Migrating Zeta Componetns to Github
Adding to this: I could use some help of course, so anyone also feeling to volunteer can do so. My idea was to create a repository with a bash/php script collection that does the migration and then collaborate on that until we have the final version to use. Starting point is here: https://github.com/zetacomponents/svn-git-migration On Fri, Apr 20, 2012 at 1:35 PM, Benjamin Eberlei kont...@beberlei.dewrote: Repost into its own topic for better seperation: I volunteered to do a migration of the code to github. I will do the following steps: 1. Do a SVN to Git migration for every component on its own. Every component will have its own repository with issue tracker on Github. 2. Rewrite history to add composer.json files to all stable tags 3. Push to Github Derick already opened an Organization on Github and I guess all current committers will get write access to it. Adding composer helps us with the deployment issue in the short term and in the medium/long term we could maybe setup a pirum channel on github pages to enable PEAR installation again. Composer can work with classmaps so that the file/class layout is no problem for autoloading and components become instantly usable by third parties. The next step would then be that committers claim components and we determine the deprecated/abandoned/ maintained state of each of them. Every maintainer is then responsible for getting the tests back running with the new schema and adding this to travis-ci. I will attempt to do this for one component as a demonstration. I can't give a timeframe on this but will highly prioritize this and hope to get it done within a week. greetings, Benjamin
Re: [zeta-dev] Testsuite Refactoring
+1 on this. Are there some recurring tasks that have to be done to do this refactoring or is it essentially trial and error? On Mon, Sep 26, 2011 at 11:34 AM, Sebastian Bergmann sebast...@apache.orgwrote: On 09/26/2011 11:31 AM, Sebastian Bergmann wrote: For as long as I have been involved in this project I have been saying Today I started to work on this. Already I am able to run the Workflow* test suites with the out-of-the-box test runner of PHPUnit 3.6. The configuration of the database connection is handled via the phpunit.xml configuration file. This is what the output looks like: ➜ trunk /usr/local/php-5.3/bin/php /usr/local/src/phpunit/** phpunit.php PHPUnit @package_version@ by Sebastian Bergmann. Configuration read from /usr/local/src/zeta/trunk/**phpunit.xml.dist ..**... 63 / 392 ( 16%) ..**... 126 / 392 ( 32%) ..**... 189 / 392 ( 48%) ..**... 252 / 392 ( 64%) ..**... 315 / 392 ( 80%) ..**... 378 / 392 ( 96%) .. Time: 11 seconds, Memory: 44.25Mb OK (392 tests, 1263 assertions) -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/
[zeta-dev] Requirements document for a Workflow CouchDB Tiein
Hello everyone, read on for my first draft of a requirements document for a Workflow CouchDB Tiein. greetings, Benjamin Zeta Components - Workflow CouchDB Tiein Design ~~~ :Author: Benjamin Eberlei Introduction Description --- The WorkflowCouchDBTiein provides functionalities to load and save workflows into CouchDB and to start, save and resume executions by persisting the state into CouchDB. Benefits of a CouchDB backend over the DatabaseTiein is the non-relational structure of a workflow. Each node and execution has different variables, state and dependencies. Additionally a relational implementation requires to split the workflow in many different tables, reducing performance during save and query operations. CouchDB could save workflow and executions in their own documents respectively, requiring only between one and three HTTP calls to CouchDB to fetch and save all the workflow related data again. Additionally having the workflows (+history) and executions in single documents makes the whole workflow process much more readable and debugable for developers. Current implementation -- I have a current implementation to figure out some of the problems that might come with using CouchDB for workflow and it helped find some problems in Workflow Base component that have to be fixed before. However the code is not tested so I will probably begin from scratch. Requirements The implementation should obviously work exactly like the base or database workflows, so that there are no differences using either one. Design goals - A thin HTTP Layer is provided with this component to speak to CouchDB so that no third dependency needs to be introduced. - Workflows, their Nodes and Executions will be assigned CouchDB UUIDs. - Workflows and executions are saved into a single document each. - Time inconsistencies due to changing workflows will be circumvented by saving all versions of the workflow into a substructure and associating each active execution with a workflow id and version. - Document JSON structures are crafted in a way that developers can implement their own queries on various variables of the execution state are possible using CouchDB views.
Re: [zeta-dev] Proposal: ezcWorkflow CouchDB Backend
Hey Paul, i already have a buggy and untested prototype of the CouchDB backend that is as small as 300 loc. I think an additional abstraction of the document layer may only complicate the implementation or just lead to all API methods being delegated to yet another backend. Its probably easier to just have an additional ezcWorkflowMongoTiein that is equally thin. Regarding the non-Update only Insert, ezcWorkflowDatabaseTiein operates exactly the same. Yes i have very long running workflows that may change often, so this is an important requirements (for me). But i think this behaviour is important for short workflows of just some minutes execution also. greetings, Benjamin On Tue, 27 Jul 2010 00:06:00 +0200, Paul Borgermans paul.borgerm...@gmail.com wrote: Hi On Mon, Jul 26, 2010 at 9:14 PM, Benjamin Eberlei kont...@beberlei.de wrote: Hello everyone, i want to propose the development of a CouchDB Storage Tiein for the Workflow Engine. It would be a considerable improvement over the Database backend, for various reasons: Maybe abstract it to have easy tie ins for other document oriented databases? 1. Several variables are saved as PHP serialize() output in LONGTEXT fields in both the Workflow and Execution parts of the Engine. This is rather problematic (and ugly). Workflow just has many unrelational parts such as node configuration, execution state/variables and thread information. CouchDB could just nest them as sub-objects in JSON. +1, and also return JSON constructs for potential use in view layers 2. Database backend uses serialized php data for Execution::$variables and Execution::$waitingFor, both variables that are interesting for querying the set of existing workflows. Views can be easily written using any of the two as keys to select for. Yes! 3. Both a workflow and an execution could be saved in a single document each. Why a workflow? Workflows are never updated, only saved with a new ID. Otherwise you could seriously destroy currently existing executions of a changed workflow. Therefore no problems exists with read/write contention or version conflicts. Fair enough, is your use-case involving long-lived workflows? About the execution, I see MongoDB as an attractive alternative too, because it allows updates in place for a single key/field, further minimizing the overhead for tracking this execution part Why an execution? It has to be resurrected from persistence completely in any case, the nested data is never of any interest in an incomplete context. You always need the whole data. Indeed, at least for as far I dived into and understand the workflow component at this stage What do you think of the idea? Is there interest in this development? I think so, but I am biased towards doc-oriented backends anyway my 0.02€ Paul
[zeta-dev] Proposal: ezcWorkflow CouchDB Backend
Hello everyone, i want to propose the development of a CouchDB Storage Tiein for the Workflow Engine. It would be a considerable improvement over the Database backend, for various reasons: 1. Several variables are saved as PHP serialize() output in LONGTEXT fields in both the Workflow and Execution parts of the Engine. This is rather problematic (and ugly). Workflow just has many unrelational parts such as node configuration, execution state/variables and thread information. CouchDB could just nest them as sub-objects in JSON. 2. Database backend uses serialized php data for Execution::$variables and Execution::$waitingFor, both variables that are interesting for querying the set of existing workflows. Views can be easily written using any of the two as keys to select for. 3. Both a workflow and an execution could be saved in a single document each. Why a workflow? Workflows are never updated, only saved with a new ID. Otherwise you could seriously destroy currently existing executions of a changed workflow. Therefore no problems exists with read/write contention or version conflicts. Why an execution? It has to be resurrected from persistence completely in any case, the nested data is never of any interest in an incomplete context. You always need the whole data. What do you think of the idea? Is there interest in this development? greetings, Benjamin
