Re: [zeta-dev] Draft: Status update blog entry
Hi Tobias, On Wed, Nov 17, 2010 at 9:48 PM, Tobias Schlitt tob...@schlitt.info wrote: Hi Jerome, [...] PS : shamefulI really have to work on that override mechanism for Configuration/shameful That'd be great. I'll try to get the wiki up for such stuff soonish, as discussed here. Did you already send an iCLA? As far as I remember I did. I know there is a page on apache.org where you can see people who sent their iCLA but I do not remember which one. Maybe Christian remembers it. -- Jérôme Renard http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard
Re: [zeta-dev] Proposal: Release process
Hi all, I'm not qualified to participate actively to the current discussions, although i'm reading it all. However, i'd like to share how it works with python/pinax projects because it might inspire you. On Thu, Nov 18, 2010 at 9:46 AM, Tobias Schlitt tob...@schlitt.info wrote: Hi Max, On 11/18/2010 09:21 AM, Maxime Thomas wrote: Actually only the packaging of zeta matters as we want to provide everything or a part of it. The jQuery UI package download system seems to be a good start, I guess. Another question comes if we do like this : will it be possible to make heterogeneous packages with this system. I mean can I ask Graph 1.0 with Config 3.2 ? or do I have a minimum rules to follow ? Pinax projects use a requierements.txt file, for example:: --extra-index-url=http://dist.pinaxproject.com/dev/ Django==1.2.1 Pinax==0.9a1 django-debug-toolbar==0.8.3 django-staticfiles==0.2.0 -e git+ssh://g...@github.com:jpic/sorl-thumbnail.git#egg=sorl-thumbnail That file is tracked by the VCS in each project. To deploy a new environment for my project, all i have to do is:: # pip is like pear, for python pip install -r requirements.txt That allows: - each project to have different component dependencies - with specific versions - deployment is piece of cake I don't think it's possible with official pear, anyway: if we decide that it's the way to go then we'll find a way. Regards James -- http://chocolatpistache.com/wiki/public/Contact Customer is king - Le client est roi - El cliente es rey.
Re: [zeta-dev] Draft: Status update blog entry
That'd be great. I'll try to get the wiki up for such stuff soonish, as discussed here. Did you already send an iCLA? As far as I remember I did. I know there is a page on apache.org where you can see people who sent their iCLA but I do not remember which one. Maybe Christian remembers it. Yes he does: http://people.apache.org/committer-index.html Your name is mentioned on the unlisted CLA section == your ICLA has been received Cheers
Re: [zeta-dev] Proposal: Release process
Another point that has maybe already been discussed but how do we manage components in the SVN, do we have separate tags and branches for the set of components and each component ? My point is to chose the easiest way to deliver things : if each package must be done manually, it increases the probability of mistakes. The best option is maybe to start with a simple package and then see what happend (some feedback of people). We can keep : - the access to SVN - the pear channel with identified version (like ezc) Max 2010/11/18 Gaetano Giunta giunta.gaet...@gmail.com James Pic wrote: Hi all, I'm not qualified to participate actively to the current discussions, although i'm reading it all. However, i'd like to share how it works with python/pinax projects because it might inspire you. On Thu, Nov 18, 2010 at 9:46 AM, Tobias Schlitttob...@schlitt.info wrote: Hi Max, On 11/18/2010 09:21 AM, Maxime Thomas wrote: Actually only the packaging of zeta matters as we want to provide everything or a part of it. The jQuery UI package download system seems to be a good start, I guess. Another question comes if we do like this : will it be possible to make heterogeneous packages with this system. I mean can I ask Graph 1.0 with Config 3.2 ? or do I have a minimum rules to follow ? Pinax projects use a requierements.txt file, for example:: --extra-index-url=http://dist.pinaxproject.com/dev/ Django==1.2.1 Pinax==0.9a1 django-debug-toolbar==0.8.3 django-staticfiles==0.2.0 -e git+ssh://g...@github.com:jpic/sorl-thumbnail.git#egg=sorl-thumbnail That file is tracked by the VCS in each project. To deploy a new environment for my project, all i have to do is:: # pip is like pear, for python pip install -r requirements.txt That allows: - each project to have different component dependencies - with specific versions - deployment is piece of cake I don't think it's possible with official pear, anyway: if we decide that it's the way to go then we'll find a way. shame on pear! otoh: would we have such info available for existing components or would it be so hard to extract it in a precise and useful way that it would not be done anyway (I mean apart from the obvious compatibility that we get from the complete bundles)? Regards James
Re: [zeta-dev] Proposal: Release process
Hi James, On 11/18/2010 10:04 AM, James Pic wrote: I'm not qualified to participate actively to the current discussions, although i'm reading it all. hoo? Why not? However, i'd like to share how it works with python/pinax projects because it might inspire you. Any kind of input is highly welcome! On Thu, Nov 18, 2010 at 9:46 AM, Tobias Schlitt tob...@schlitt.info wrote: On 11/18/2010 09:21 AM, Maxime Thomas wrote: Actually only the packaging of zeta matters as we want to provide everything or a part of it. The jQuery UI package download system seems to be a good start, I guess. Another question comes if we do like this : will it be possible to make heterogeneous packages with this system. I mean can I ask Graph 1.0 with Config 3.2 ? or do I have a minimum rules to follow ? Pinax projects use a requierements.txt file, for example:: --extra-index-url=http://dist.pinaxproject.com/dev/ Django==1.2.1 Pinax==0.9a1 django-debug-toolbar==0.8.3 django-staticfiles==0.2.0 -e git+ssh://g...@github.com:jpic/sorl-thumbnail.git#egg=sorl-thumbnail That file is tracked by the VCS in each project. To deploy a new environment for my project, all i have to do is:: # pip is like pear, for python pip install -r requirements.txt That allows: - each project to have different component dependencies - with specific versions - deployment is piece of cake I don't think it's possible with official pear, anyway: if we decide that it's the way to go then we'll find a way. With PEAR such dependencies are handeled fine and we already reflect them in the $component/DEPS file. However, for building automated packages on the fly for downloading, I think there will be some more effort to take. Don't get me wrong, I insist of keeping our PEAR channel as the primary distribution way. We are only talking about the full package here. 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
