Re: Migrating Zeta Componetns to Github
2012/4/20 Benjamin Eberlei : > 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 I'd like to help here since I have a bit of this experience having moved eZ Publish to github. I already shared the script using a PR: https://github.com/zetacomponents/svn-git-migration/pull/1 I also have a local users.txt containing all the information of users having committed code to ezc/zeta but since it contains e-mail addresses, I don't really know if I should push it on github and/or send it here as attachment or even using a private gist. Feel free to have suggestion. Cheers, Patrick
Re: Migrating Zeta Componetns to Github
2012/4/20 James Pic : > I love this idea ! Make zeta components a coding standard rather than a > centralized repo of libraries is kind of the holy grail for me ... > > In that case I only see one issue: dependency management. How should the > user specify that he wants this and that component of this or that version ? > > What if a user wants to depend on a component in its trunk version, or even > from his personal fork ? It should be super easy if we want people to fork > and issue pull requests. > > I am not aware that PEAR is capable of installing stuff directly from > github, like pip does for python*. I eared compozer would be able to do > that one day. > > I think it's worth the experiment. > > Regards > > * > http://blog.yourlabs.org/post/19725807220/django-pinax-virtualenv-setuptools-pip I think we should keep this thread focused on the migration of Zeta to github. Feel free to change the subject to match the topic better.
Re: [zeta-dev] PHP based build system : Phing VS Pake
2011/4/18 Patrick ALLAERT : > 2011/4/12 Jerome Renard : >> >> I plead guilty for imposing Ant, the reason is that I have been using >> it for a couple >> of years already and I thought it would solve problems we got in the >> Makefile. But I >> was wrong. >> > > Oh oui oh oui, je veux voir ça plus souvent :D > > Patrick ;) My bad. This is what happen when you "Reply to all" when you just want to reply to the author. The best I can do is, at least, to translate my above perversity: "Oh yes, I'd like to see that more often :D" ps: sorry for the annoyance. -- Patrick
Re: [zeta-dev] PHP based build system : Phing VS Pake
2011/4/12 Jerome Renard : > > I plead guilty for imposing Ant, the reason is that I have been using > it for a couple > of years already and I thought it would solve problems we got in the > Makefile. But I > was wrong. > Oh oui oh oui, je veux voir ça plus souvent :D Patrick ;)
Re: [zeta-dev] Proposal: Commit guidelines
2011/4/8 Jerome Renard : > Hi Thomas, > > On Fri, Apr 8, 2011 at 11:09 AM, Thomas Nunninger > wrote: >> Hi, >> >> Am Freitag, 8. April 2011 07:50:20 schrieb Jerome Renard: >>> Hi Patrick, >>> >>> On Thu, Apr 7, 2011 at 4:09 PM, Patrick ALLAERT >>> >>> wrote: >>> > 2011/4/1 Tobias Schlitt : >>> >> Hi, >>> >> >>> >> I wrote down our commit guidelines. Please review them shortly, before I >>> >> commit: >>> >> >>> >> http://files.schlitt.info/tmp/commit_guidelines.patch >>> > >>> > Good work Toby! >>> > >>> > I have however a remark regarding: >>> > >>> > +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. >>> > >>> > I think having the issue number on the latest commit only might be a >>> > problem for different reasons: >>> > 1. While looking at a commit mentioning an issue ID, you have no clue >>> > whether other commits are required or not to fix that specific issue. >>> > 2. In the case a commit fixing a bug has to be reverted for whatever >>> > the reason, the one which will definitely resolve the problem will >>> > also mention that issue which is not consistent to the guidelines. >>> > 3. In the case a bug issue is reopened, we might have the same problem as >>> > in 2. >>> >>> I already thought about this problem but to be honnest I never found >>> an acceptable >>> solution. The only "solution" I came up with is to write commit log >>> message like this: >>> >>> - Fixed #1234321 part 1 : bla bla bla bla >> >> Perhaps it's possible to come up with some other (fixed) term instead of >> "part >> X" after the issue number. A term that means something like: "not >> finished", "to be continued" or whatever. It shouldn't be to long. Perhaps an >> abbreviation. >> > > Why not, how about something like this ? > > - Fixed #XXX : bla bla bla START > - Fixed #XXX : bla bla bla WIP > [...] > - Fixed #XXX : bla bla bla END Should we really mention all that info? I would propose to only use: - Fixed #XXX: ... Normal case is generally to fix issues in one single commit. But it happens that a fix does not fully solve the problem and the bug to be reopened. I think we can simply have something like: First commit solving ZETACOMP-XX: "- Fixed #ZETACOMP-XX: Double conversion of HTML entities" Second commit because of a special case not covered by initial fix: "- Fixed #ZETACOMP-XX: Double conversion of HTML entities Covering the case when ..." This way it is quite easy to look (grep) at "Fixed #ZETACOMP-XX:" for commits related to that issue, knowing that all those commits are required to fully fix the problem. Cheers, Patrick -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor
Re: [zeta-dev] Proposal: Commit guidelines
2011/4/1 Tobias Schlitt : > Hi, > > I wrote down our commit guidelines. Please review them shortly, before I > commit: > > http://files.schlitt.info/tmp/commit_guidelines.patch Good work Toby! I have however a remark regarding: +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. I think having the issue number on the latest commit only might be a problem for different reasons: 1. While looking at a commit mentioning an issue ID, you have no clue whether other commits are required or not to fix that specific issue. 2. In the case a commit fixing a bug has to be reverted for whatever the reason, the one which will definitely resolve the problem will also mention that issue which is not consistent to the guidelines. 3. In the case a bug issue is reopened, we might have the same problem as in 2. Those issue are mostly annoying for bugs. Is there a drawback that every commits related to an issue is using the same format as for the final one? Using it systematically for bugs and not for feature request is a possible workaround, but it introduces a difference in the process of handling issues depending on the type we might want to avoid. Cheers, Patrick
Re: [zeta-dev] Naming convention : *List variables
2011/3/7 Jerome Renard : > Hi there, > > I would propose a small addition to the naming conventions. > > A list of recommended names is already provided in > http://incubator.apache.org/zetacomponents/community/implementation.html#general-guidelines > however there is nothing proposed for variables like arrays. > > As an example you can compare the two following snippets > > Without "List" variable: > $rows = fetchSomeRows(); > foreach($rows as row) > [] > > With "List' variable: > $rowList = fetchSomeRows(); > foreach($rowList as $row) > [] > > The rationale for such variable names is that adds a bit more > semantics on what the variable > is supposed to contains. It should also help to avoid typos which > makes debugging harder. > > What do you think ? Regarding your example, I generally prefer using the plural form or "$row" being "$rows" than adding extra semantics. Being too verbose sometimes leads to: $messageString = "Hello World"; $ultimateAnwserInteger = 42; instead of: $message = "Hello World"; $ultimateAnwser = 42; There is nothing wrong being explicit about the content of the variable, but I would refrain from using types like "Array", "List", "Integer",... My 2 cents, Patrick
Re: [zeta-dev] Getting our lazy bums up: Marketing Zeta!
2011/3/4 Tobias Schlitt : > Hi all, > > I talked to Nicolas (eZ) during PHP UK and we both agreed that one thing > that Zeta definitely needs is *more marketing*! In any direction, I > would like to ask you to spread the word about this amazing project to > achieve the following goals: > > - Attract more contributors > - Attract more users > - Make the world know that Zeta exists > > There are several ways how everyone of you can help use to achieve these > goals. A small brain dump from me: > > - Propose conference talks > - Organize booths on OSS exhibitions > - Present at your local user group > - Talk to co-workers about it > - Tell people on Twitter > - Write blog posts > > Do you have more ideas? Please post them here! Increasing the presence of Zeta Components on sites like Wikipedia. I've just created the page: http://en.wikipedia.org/wiki/Zeta_Components but this is just a WIP. Cheers, Patrick
Re: [zeta-dev] [VOTE] New committers: Jérôme Renard & Benjamin Eberlei
2011/3/4 Tobias Schlitt : > Add Jérôme Renard as a committer: > > [ X] +1 (yes) > [ ] -1 (no, because …) > [ ] 0 (don't care) > > Add Benjamin Eberlei as a committer: > > [X ] +1 (yes) > [ ] -1 (no, because …) > [ ] 0 (don't care) Cheers, Patrick
Re: [zeta-dev] [VOTE] Release process
[X] +1 (accept release process) [ ] 0 (I don't care) [ ] -1 (decline release process, because …) Very great job Tobias! Patrick
Re: [zeta-dev] Vote ahead: Release process
2010/12/10 Tobias Schlitt : > Hi, > > there seems to be no more significant feedback about the release process > anymore. Therefore I'd like to open the vote about it on upcoming Monday > (regular 72 hrs. vote), because I will leave for 2 weeks vacation next > Sunday and want to have this thing done beforehand. > > Anyone against this schedule? Nope :) > Regards, > Toby > > -- > Tobias Schlitt http://schlitt.info GPG 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] [VOTE] Documenting coding style
2010/12/10 Tobias Schlitt : > Hi, > > since there was no further feedback on my patch for the coding style > documentation, I'd like to call for votes on it. Find the patch to vote > on attached again. > > Please vote > > [ ] +1 yes, this is our official coding style > [ ] 0 I don't care > [ ] -1 no, I disagree, … $because … > > The vote will last 120 hours (72 standard voting time + weekend). > > Regards, > Toby > > -- > Tobias Schlitt http://schlitt.info GPG Key: 0xC462BC14 > Want to hire me? Need quality assurance? http://qafoo.com > eZ Components are Zeta Components now! http://bit.ly/9S7zbn [X] +1 yes, this is our official coding style
Re: [zeta-dev] Proposal: Release process
2010/11/29 Manuel Pichler : > Hi Toby, > > Am Montag, den 29.11.2010, 11:21 +0100 schrieb Tobias Schlitt: > [...] >> >> On 11/17/2010 03:58 PM, Jerome Renard wrote: >> >> However, for a custom app, it does not make sense to bundle all Zeta >> >> Components if you only want to use e.g. Graph or Mail (which are 2 of >> >> the most used components). > [...] >> I really doubt there is enough value in providing customized package >> downloads for Zeta compared to the hassle. > > here I totally disagree with you. IMHO is it bad practice to force > someone to download the complete package, even when only a few > components are needed. I would even go so far as to say that it is a > must have for each serious framework to allow cherry-picking of the > components you would like to use. Same here! Especially in the case of the Zeta components where most of the components are highly decoupled and individually usable! I wouldn't say the same thing in the case of a highly coupled framework like Symfony or Zend Framework! Patrick
Re: [zeta-dev] Proposal: Release process
2010/11/16 Gaetano Giunta : > Maxime Thomas wrote: >> >> Sound strange, if we look at what is done elsewhere : >> >> - JQuery UI : shared version number >> - Zend : shared version number >> - Former eZComponents : both version number >> > also YUI >> >> The shared version number implies a kind of packaged application. Else it >> can be difficult to install and maintain (same as Gaetano). >> >> Max >> >> 2010/11/16 Patrick ALLAERT >> >>> 2010/11/16 Gaetano Giunta: >>>> >>>> Tobias Schlitt wrote: >>>>> >>>>> Hi Thomas, >>>>> >>>>> On 11/07/2010 11:55 AM, Thomas Ernest wrote: >>>>> >>>>>> Le 04/11/2010 17:28, Tobias Schlitt a écrit : >>>>>>> >>>>>>> docs/release_process.txt >>>>>> >>>>>> It is a very interesting and useful synthesis. Thank you. >>>>>>> >>>>>>> The document summarizes the requirements for releases roughly and >>>>>>> then >>>>>>> tries to relealize these in a release process specific to Zeta. >>>>>>> >>>>>>> There are some open issues marked with notes in this document, which >>>>>>> need to be decided on. >>>>>> >>>>>> I read the document and I focused on the two next issues (or notes) : >>>>>>> >>>>>>> .. note:: Incubating phase (around line 118) >>>>>> >>>>>> I don't understand what is the matter with this one. Could you tell me >>>>>> more please ? >>>>> >>>>> We are currently incubating, which means we are under deeper control of >>>>> the ASF. For a release that means we need to perform 2 steps before >>>>> uploading it to the servers: >>>>> >>>>> 1. Vote here on the list >>>>> 2. Have a second vote on the Incubator PMC list >>>>> >>>>> Step 1 will also be mandatory once we have been promoted to be a top >>>>> level project. Step 2 is only mandatory before that. >>>>> >>>>> I hope that made it clearer? >>>>> >>>>>>> .. note:: Determine release times. (around line 155) >>>>>> >>>>>> It seems that a full package release is a packaging of all last >>>>>> *stable* component releases. Hence, a full package release could be >>>>>> rolled automatically after every component release. >>>>> >>>>> We did not realize such a procedure until now for two reasons: >>>>> >>>>> 1. Releasing was not that easy in the eZ Components project >>>>> 2. Updating the full package install is cumbersome work for users >>>>> >>>>> I'd pretty much love to get rid of 1 for Zeta Components, so that >>>>> should >>>>> not be an issue in the future. However, the full package cannot be >>>>> installed automatically by users. They need to manually unpack stuff. >>>>> This kind of release is pretty much useful for people who just want to >>>>> take a first look and play around with the code. >>>>> >>>>> However, I personally would love to have such automatic package builds, >>>>> as I would love nightly builds, too. It's just quite some work to >>>>> realize this and we need a volunteer to take care for it. And I'm not >>>>> sure if everyone agrees with my views here. >>>>> >>>>>> So, I see full package release as a sub part of component release >>>>>> process, which involves that : >>>>>> - There is no need for release time. >>>>>> - There is no need for votes. >>>>> >>>>> That would indeed save some bureaucratic hassle, yes. :) >>>>> >>>>>> This possibility relies on the assumption that a full package release >>>>>> hasn't more value-added (or worth) than sum of stable component >>>>>> releases. It means that there is no additional deployment mechanism in >>>>>> full package releases for instance. >>>>> >>>>> No, so far the full package releases only contained stable component >>>>> versions, which were also distributed through the PEAR cha
Re: [zeta-dev] Proposal: Release process
2010/11/16 Gaetano Giunta : > Tobias Schlitt wrote: >> >> Hi Thomas, >> >> On 11/07/2010 11:55 AM, Thomas Ernest wrote: >> >>> Le 04/11/2010 17:28, Tobias Schlitt a écrit : >>>> >>>> docs/release_process.txt >>> >>> It is a very interesting and useful synthesis. Thank you. >>>> >>>> The document summarizes the requirements for releases roughly and then >>>> tries to relealize these in a release process specific to Zeta. >>>> >>>> There are some open issues marked with notes in this document, which >>>> need to be decided on. >>> >>> I read the document and I focused on the two next issues (or notes) : >>>> >>>> .. note:: Incubating phase (around line 118) >>> >>> I don't understand what is the matter with this one. Could you tell me >>> more please ? >> >> We are currently incubating, which means we are under deeper control of >> the ASF. For a release that means we need to perform 2 steps before >> uploading it to the servers: >> >> 1. Vote here on the list >> 2. Have a second vote on the Incubator PMC list >> >> Step 1 will also be mandatory once we have been promoted to be a top >> level project. Step 2 is only mandatory before that. >> >> I hope that made it clearer? >> >>>> .. note:: Determine release times. (around line 155) >>> >>> It seems that a full package release is a packaging of all last >>> *stable* component releases. Hence, a full package release could be >>> rolled automatically after every component release. >> >> We did not realize such a procedure until now for two reasons: >> >> 1. Releasing was not that easy in the eZ Components project >> 2. Updating the full package install is cumbersome work for users >> >> I'd pretty much love to get rid of 1 for Zeta Components, so that should >> not be an issue in the future. However, the full package cannot be >> installed automatically by users. They need to manually unpack stuff. >> This kind of release is pretty much useful for people who just want to >> take a first look and play around with the code. >> >> However, I personally would love to have such automatic package builds, >> as I would love nightly builds, too. It's just quite some work to >> realize this and we need a volunteer to take care for it. And I'm not >> sure if everyone agrees with my views here. >> >>> So, I see full package release as a sub part of component release >>> process, which involves that : >>> - There is no need for release time. >>> - There is no need for votes. >> >> That would indeed save some bureaucratic hassle, yes. :) >> >>> This possibility relies on the assumption that a full package release >>> hasn't more value-added (or worth) than sum of stable component >>> releases. It means that there is no additional deployment mechanism in >>> full package releases for instance. >> >> No, so far the full package releases only contained stable component >> versions, which were also distributed through the PEAR channel earlier. >> >>> Here comes questions : >>> A/ What is your opinion about the proposal automate full package release >>> ? >>> B/ What are advantages of separating full package release process from >>> component release process ? (It should probably be my first question >>> before writing all this stuff :-)) >> >> For A: I would love to see such a process, as said above. >> >> For B: An advantage of the previous process was, that component >> maintainers always tried to have features ready by a defined date, so >> that they can become part of the full package release. However, I think >> a more agile way, which allows us to release more fast and often would >> be nice. >> > > As an end user, sysadmin and app developer, the idea of having per-component > release makes my head hurt. > > While I agree that a more agile build infrastructure is a bonus, as "user of > the library" I do not need at all separate components versions released > independently. How could I possibly test the new zeta-c versions, pick the > ones to integrate in my projects, decide on timing of upgrades, when a new > component might be released every other week? > There's a reason the whole world is moving to a 6-months release cycle + > immediate security fixes. > > My 2c > Gaetano > > ps: in my very limited experience using the java components from the ASF for > eg. an http client and logging, picking the versions of the different parts > was exactly one of the sore points. I personally appreciate the very low coupling between the components even at the release level! It enables a smooth upgrade of a specific component without caring about a possible change in another one. Lot of effort is done to keep components as independent as possible between them. To some extend, they only share common best practices and the name. So why sharing a common release number? Patrick -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor
Re: [zeta-dev] Contributing / ZETACOMP-8
Hi Christian, 2010/8/24 Christian Grobmeier : >> For future reference, the best way to send ICLAs to Apache is to print, >> sign, scan, and email the pdf document, exactly as Patrick did. >> >> Patrick's ICLA was filed this morning. > > Is the name really Patrick Allert? > From the mails shouldn't it be AllAert? > > From: http://people.apache.org/committer-index.html#unlistedclas Thanks for notifying, it is indeed Allaert and not Allert. Regards, Pattrick
Re: [zeta-dev] Contributing / ZETACOMP-8
Hi Christian, 2010/8/23 Christian Grobmeier : > Hello Patrick, > > thanks for contributing. > I would like to point you to these links, which help you to understand > Apache and how it all works: > > * http://www.apache.org/foundation/getinvolved.html > * http://www.apache.org/foundation/how-it-works.html Thanks for the links, this is indeed how I expected things to work in FOSS/Apache projects. > Additionally its a good idea to attach your patch to the ticket in > Jira directly. Please don't forget to check the check box which allows > developers to include your code. Done. > Having a signed CLA is always a good > idea if you are interested in contributing more stuff. A "formal > application" is not necessary anyway, A project elects its committers > after after a contributor has shown a understanding and "commitment". Thanks Christian for clarifying this. I have just sent my CLA to the secretary. > Best regards, > Christian Kind regards, Patrick > On Mon, Aug 23, 2010 at 10:15 AM, Patrick ALLAERT > wrote: >> Hi devs, >> >> I would like to be able to contribute to the Zeta Components project >> as a developer. >> I would mainly start solving issues as well as some QA stuff like >> fixing tests which does not pass on every platform. >> >> My first contribution, if you accept it, would be to solve issue: >> "ZETACOMP-8: [Archive] Double extraction causes empty file" >> which you might review here: >> http://pallaert.pastebin.com/3J7duMF1 >> >> A special crafted tar is needed for this test to reproduce it. I've >> been able to create one which is attached to this e-mail. >> >> I have signed an Apache CLA I will send to the Foundation in the case >> you would accept my application. >> >> Kind regards, >> Patrick Allaert
[zeta-dev] Contributing / ZETACOMP-8
Hi devs, I would like to be able to contribute to the Zeta Components project as a developer. I would mainly start solving issues as well as some QA stuff like fixing tests which does not pass on every platform. My first contribution, if you accept it, would be to solve issue: "ZETACOMP-8: [Archive] Double extraction causes empty file" which you might review here: http://pallaert.pastebin.com/3J7duMF1 A special crafted tar is needed for this test to reproduce it. I've been able to create one which is attached to this e-mail. I have signed an Apache CLA I will send to the Foundation in the case you would accept my application. Kind regards, Patrick Allaert
Re: [zeta-dev] PHPUnit's usage
2010/8/20 Sebastian Bergmann : > Am 19.08.2010 21:25, schrieb apa...@derickrethans.nl: >> Yes, definitely. I've mentioned it to Sebastian before many times as >> well in th epast... > > This would be a non-issue if the Zeta Components would use PHPUnit > properly. Do you mean that if the Zeta Components would use PHPUnit properly, we could be able to stick to PHPUnit 3.4? Now that it relies on 3.5+, is the usage suddenly correct? I don't understand the link between the fact (or not) of an improper usage of PHPUnit and depending on a non stable version. My only concern here is that I constantly have to switch PHPUnit's version when I want to run the test suite of the ZC or from the product built upon them. Upgrading the product to be compatible to a non stable version of PHPUnit is a no-go. Am I correct saying there is 2 issues then: 1° Relying on a non stable version of PHPUnit. 2° Improper usage of PHPUnit Regards, Patrick
Re: [zeta-dev] [Vote] Restricted wiki usage
+1 However, in the future it might be better to have it allowed to committers + wiki editors, so that wiki access can be granted without svn commit rights.
[zeta-dev] PHPUnit's usage
Hi zeta devs, Would it be possible to consider using a stable version of PHPUnit in trunk? Trying to run both the testsuite of the Zeta Components as well as the one of the solution I am building upon the ZC is quite annoying. ZC currently uses PHPUnit 3.5+ while (I guess) most of the products running on it uses a stable version of PHPUnit. This is making hard testing/contributing to the ZC. Regards, Patrick
