Re: [zeta-dev] Piwi and ZC (was: Re: [zeta-dev] Re: Class prefix change, was: Re: [zeta-dev] Welcome Apache Zeta Components - SVN up and running :))
Hello everyone, On Thu, 2010-08-19 at 13:40 +0200, Christian Grobmeier wrote: [...] > However I would like to know if there has been a decision meanwhile on > the prefix issue (see below). I would like to avoid to include ZC > before this change has been done, if it is going to happen. > > My preference is to change it. Its basically a complete rebrand and > when ZC offers some kind of helper script for users to at least > announce the files which use the wrong prefix, everything should be > pretty ok. I also think it's the last chance to do such a change. When > the next release is out people will claim about backwards > compatiblity. > > OK would like to hear you opinions on the prefix change. I think this is a 100% no go for a product that claims to be enterprisy. Even when I would like to see namespaces, instead of this annoying prefixes, I would not recommend to do such a BC break. I have used several components of eZ/Zeta in many projects during the lastfive years and such a change will break all of them or they cannot be updated. I am really sure that most of project owners are not willing to pay for this refactoring, at least not in the next few weeks/months. In my opinion such a critical BC-break would let many(maybe most) users leave the project, because what can I expect from a project in the long-term, when these changes are done adhoc, without a long-tail-support phase. Just my 2 cent Manuel
Re: [zeta-dev] Reasonable restrictions of wiki use
Sorry for the delay in responding. Projects have run wikis with different policies. The podling's governing group (PPMC) needs to decide on the policy and implement it. All I'm offering is different policies that you can consider. Craig On Aug 18, 2010, at 2:42 AM, Christian Grobmeier wrote: thanks for your input. I think this is quite valuable. To which degree do we need to care about taking over stuff from the wiki into our real docs, if a user without iCLA contributed it? Let me give an example: If a user writes a short example code snippet (whatever 3-5 lines) which we would consider valuable to have in the real docs, would he need to sign an iCLA? I wouldn't worry too much about 3-5 LOC. But it might be easier on all concerned to err on the side of caution. thats surely the easier and more secure way. However, I doubt that many of our users will have signed an iCLA, so our purpose for the wiki might be lead ad absurdum somehow. Are you all speaking about signing a CLA before contributing to a wiki? I am not sure about all the legal stuff, but is it really necessary to restrict a wiki so much? For example at commons.apache.org everybody can write to a wiki. Changes are mailed to the dev list. If there is something weird devs could interact. For my taste I would keep restrictions as low as possible while having an initial "frame" of the content like Tobias said is a very good idea. If it does not work out well it can be changed later at any time. Christian Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp!
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] Re: Class prefix change
Kore Nordmann wrote: On Thu, 2010-08-19 at 21:28 +0200, Derick Rethans wrote: On Thu, 19 Aug 2010, Christian Grobmeier wrote: My preference is to change it. Its basically a complete rebrand and when ZC offers some kind of helper script for users to at least announce the files which use the wrong prefix, everything should be pretty ok. I also think it's the last chance to do such a change. When the next release is out people will claim about backwards compatiblity. OK would like to hear you opinions on the prefix change. I would like to change it too. We're Apache Zeta Components now. Besides the rebrand, because this is a BC breaking change, we should also go through the code and clean up the @apichange bits. I still strongly oppose any BC breaks. ezc is used a lot in different applications (I alone maintain 4 or 5) - and it would be a hell lot of work to verify that those still work properly. BC is one of the key points for ezc / zeta - and breaking with this is something I would really really dislike to see. A prefix does not mean anything anyways, it is just a prefix… +1 Imho all the fuss over class name prefix is unjustified: it is just a matter of style after all - it's the part of the name that comes after the prefix that is actually important to get right. While I can understand the desire for change of new developers, bc is much more important, unless we agree that current user base is non existent. It also has long been one of the main selling points of the ezc (ie. "we are more stable than other frameworks"), so a deliberate break would entail a revision of the core development principles. bye Gaetano
Re: [zeta-dev] [Vote] Restricted wiki usage
On Thu, 2010-08-19 at 16:50 +0200, Tobias Schlitt wrote: > Hi, > > since there were no further comments on the wiki restrictions I > proposed, I herefore ask you to vote on the following solution: > > - Restrict editing of the Zeta wiki overall to Zeta committers > - Open 2 kinds of sections up for every registered wiki user: > 1. A proposal area > 2. A dedicated area for each component for user comments > > Please vote: > > [ ] +1 (yes, implement this as a first step) > [ ] -1 (no) > [ ] 0 (I don't care) 0 I am undecided between a wiki, which does not really work as a wiki, because it is limited to some users only, and the maintenance effort involved with opening it up. Kind regards, Kore -- Kore Nordmann(GPG 0xDDC70BBB) - What I do: http://kore-nordmann.de/portfolio.html - Motivate me: http://wishlist.kore-nordmann.de/ - Hire me: http://qafoo.com/ signature.asc Description: This is a digitally signed message part
Re: [zeta-dev] Re: Class prefix change
On Thu, 2010-08-19 at 21:28 +0200, Derick Rethans wrote: > On Thu, 19 Aug 2010, Christian Grobmeier wrote: > > > My preference is to change it. Its basically a complete rebrand and > > when ZC offers some kind of helper script for users to at least > > announce the files which use the wrong prefix, everything should be > > pretty ok. I also think it's the last chance to do such a change. When > > the next release is out people will claim about backwards > > compatiblity. > > > > OK would like to hear you opinions on the prefix change. > > I would like to change it too. We're Apache Zeta Components now. Besides > the rebrand, because this is a BC breaking change, we should also go > through the code and clean up the @apichange bits. I still strongly oppose any BC breaks. ezc is used a lot in different applications (I alone maintain 4 or 5) - and it would be a hell lot of work to verify that those still work properly. BC is one of the key points for ezc / zeta - and breaking with this is something I would really really dislike to see. A prefix does not mean anything anyways, it is just a prefix… Kind regards, Kore -- Kore Nordmann(GPG 0xDDC70BBB) - What I do: http://kore-nordmann.de/portfolio.html - Motivate me: http://wishlist.kore-nordmann.de/ - Hire me: http://qafoo.com/ signature.asc Description: This is a digitally signed message part
