Re: [zeta-dev] Vote ahead: Release process
Ok. Enjoy your holidays. 2010/12/10 Patrick ALLAERT > 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 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 > -- Maxime maxime.tho...@wascou.org | www.wascou.org | http://twitter.com/wascou
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 > > [X] +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 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 > -- Maxime maxime.tho...@wascou.org | www.wascou.org | http://twitter.com/wascou
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] [VOTE] Documenting coding style
[X ] +1 yes, this is our official coding style Ronan 2010/12/10 Christian Grobmeier > > IMO, in this case just having a lazy consensus is good enough. > > +1 > > >> [X] +1 yes, this is our official coding style > > +1 (i guess non-binding in this case ;-)) > > Cheers > Christian >
Re: [zeta-dev] Vote ahead: Release process
Sounds good from here too :) -- Ronan Guilloux 2010/12/10 Jerome Renard > Hi Tobias, > > On Fri, Dec 10, 2010 at 11:38 AM, Tobias Schlitt > wrote: > > 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. > > > > Sounds good :) > > -- > Jérôme Renard > http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard >
Re: [zeta-dev] [VOTE] Documenting coding style
> IMO, in this case just having a lazy consensus is good enough. +1 >> [X] +1 yes, this is our official coding style +1 (i guess non-binding in this case ;-)) Cheers Christian
Re: [zeta-dev] [VOTE] Documenting coding style
On Fri, 10 Dec 2010, Tobias Schlitt wrote: > 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. IMO, in this case just having a lazy consensus is good enough. > [X] +1 yes, this is our official coding style > [ ] 0 I don't care > [ ] -1 no, I disagree, … $because … regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] [VOTE] Documenting coding style
Tobias, On Fri, Dec 10, 2010 at 11:22 AM, Tobias Schlitt wrote: > 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 > [X] +1 yes, this is our official coding style -- Jérôme Renard http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard
Re: [zeta-dev] [VOTE] Documenting coding style
> [X ] +1 yes, this is our official coding style > [ ] 0 I don't care > [ ] -1 no, I disagree, … $because … Julien
Re: [zeta-dev] Vote ahead: Release process
Hi Tobias, On Fri, Dec 10, 2010 at 11:38 AM, Tobias Schlitt wrote: > 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. > Sounds good :) -- Jérôme Renard http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard
[zeta-dev] Vote ahead: Release process
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? 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
Re: [zeta-dev] Update: Proposal: Release process
Hi Julien, On 12/10/2010 10:35 AM, Julien Vermillard wrote: > For me the release process is good. > I would add a line giving the mailing list were to announce the > release, like : "annou...@apache.org" and other zeta/php related > websites. sounds sane, I added a corresponding part. See the attached patch. 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 Index: release_process.txt === --- release_process.txt (revision 1043082) +++ release_process.txt (working copy) @@ -163,6 +163,15 @@ tracking the release, casting the necessary votes and for packaging and distributing it. +Announcements += + +Every publically available release must be announced through the official +Apache announcement list at ``annou...@apache.org``. Furthermore, there should +a news entry be published on the website in ``news/``. It is also desirable +that community members (maybe the release manager) blog about the release so +the word is spread wide enough. + .. Local Variables:
Re: [zeta-dev] Update: Proposal: Release process
Hi Henri,
On 12/07/2010 04:21 PM, Henri Bergius wrote:
> On Tue, Dec 7, 2010 at 5:12 PM, Tobias Schlitt wrote:
>> - full-package releases twice a year with somewhat fixed dates
> We discussed this a bit on the IRC, and I proposed following the
> general open source synchronized six month release schedule. This
> typically means Feb/Aug for libraries, Mar/Sep for applications, and
> Apr/Oct for distributions. This helps the downstream in two ways:
yeah, the previous rule we had was "before X-mas" and "before summer
vacation". That does not fit the Feb/Aug rule perfectly, but is close
enough to fit the schedule for other projects. Right?
> * People writing applications that depend on Zeta have a reliable
> schedule they can work with ("I know feature X will be there in
> February 2011"). They also have enough time to update their
> application to use the latest library before distributions ship
This point could become a bit hard, since I don't expect that people
know exactly beforehand, what features will be ready to be released.
However, having these fixed dates is a good incentive for maintainers to
have their stuff ready by time.
> * If we want to have Zeta in distributions, then each
> Ubuntu/Fedora/whatever release will have a fresh Zeta version
> Some related links:
> http://lwn.net/Articles/345353/
> http://bergie.iki.fi/blog/midgard-benefits_of_synchronized_releases/
Sounds neat.
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] [VOTE] Documenting coding style
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 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
Index: guidelines/implementation.txt
===
--- guidelines/implementation.txt (revision 978835)
+++ guidelines/implementation.txt (working copy)
@@ -1167,6 +1167,171 @@
original string and the lowercase string at the same time or using only
lowercase characters at all times.
+
+Coding standard
+===
+
+The Zeta coding standard is derived from the coding guidelines used in eZ
+Publish. It may feel uncommon to you, if you coded in the manner of PEAR
+before, but it feels a lot more readable, once you get used to it. Please stick
+to the following rules, when you provide code to Apache Zeta Components.
+
+Names
+-
+
+All names are in nerdCase (headless camel case). This applies to variable,
+property, function method and also class names. Examples are::
+
+class ezcWebdavTransport
+
+static public $parsingMap = array();
+
+public final function parseRequest( $uri )
+
+$response->validateHeaders();
+
+Note that class names always start with the prefix ``ezc``, so the actual name
+of the class is in CamelCase. The only exception for this naming rule are class
+constants, which are written fully in UPPERCASE and, if they consist of
+multiple words, are devided by underscores (``_``). For example::
+
+const VERSION = '//autogentag//';
+
+const XML_DEFAULT_NAMESPACE = 'DAV:';
+
+For conventions on names, please rever to the `Naming conventions`_ section.
+
+Brackets
+
+
+There are three simple rules on how you need to handle brackets:
+
+Parenthesis
+~~~
+
+After every opening parenthesis and before every closing parenthesis there is a
+whitespace::
+
+if ( ( $someThing === 'some' || $anotherThing === 'another' ) )
+
+The whitespace is typically a simple space character, but might also be a
+newline, if you need to indent code in parenthesis.
+
+Square brackets
+~~~
+
+There is no space after an opening square bracket and none before the closing
+conterpart::
+
+$this->properties['namespaceRegistry'] = null;
+
+Curly brackets
+~~
+
+Every curly bracket is preceeded and followed by a newline::
+
+public final function parseRequest( $uri )
+{
+// â¦
+if ( isset( self::$parsingMap[$_SERVER['REQUEST_METHOD']] ) )
+{
+try
+{
+// â¦
+}
+catch ( Exception $e )
+{
+// â¦
+}
+}
+// â¦
+}
+
+The only exception for this rule are curly brackets inside double quoted
+strings, which are used to mark a variable replacement::
+
+$foo "This is a {$foo} string with {$bar[23]}";
+
+Line length
+---
+
+A code line should not be longer than 80 characters. In case a line in your
+source code becomes longer, you need to wrap it and use proper `Indentation`_.
+
+Proper wrapping and indentation depends on the situation. For example, for a
+method signature, a proper wrapping would be::
+
+public function doSomething(
+ezcSomeClass $foo,
+ezcAnotherClass $bar,
+$doItRight = true,
+$someIntValue = 10
+)
+
+In case of a long condition, you should try to group the condition elements
+semantically, as good as possible::
+
+if ( ( $someThing === 'some' || $anotherThing === 'another' )
+&& ( $foo !== $bar ) )
+
+Indentation
+---
+
+Indentation is performed by **four spaces**, tabs or a different ammount of
+spaces for indentation is not allowed. Code blocks are indented in two
+different cases:
+
+1. After an opening curly bracket
+2. In case a code line becomes to long
+
+Properly indented code looks like this::
+
+public final function parseRequest( $uri )
+{
+$body = $this->retrieveBody();
+$path = $this->retrievePath( $uri );
+
+if ( isset( self::$parsingMap[$_SERVER['REQUEST_METHOD']] ) )
+{
+try
+{
+// Plugin hook beforeParseRequest
+ezcWebdavServer::getInstance()->pluginRegistry->announceHook(
+__CLASS__,
+'beforeParseRequest',
+new ezcWebdavPluginParameters(
+array(
+'path' => &$path,
+'body' => &$body,
+)
+)
+
Re: [zeta-dev] Update: Proposal: Release process
Hi,
For me the release process is good.
I would add a line giving the mailing list were to announce the
release, like : "annou...@apache.org" and other zeta/php related
websites.
Julien
On Thu, Dec 9, 2010 at 1:40 PM, Jerome Renard wrote:
> Hi,
>
> On Tue, Dec 7, 2010 at 4:21 PM, Henri Bergius wrote:
>> Hi,
>>
>> On Tue, Dec 7, 2010 at 5:12 PM, Tobias Schlitt wrote:
>>> - full-package releases twice a year with somewhat fixed dates
>>
>> We discussed this a bit on the IRC, and I proposed following the
>> general open source synchronized six month release schedule. This
>> typically means Feb/Aug for libraries, Mar/Sep for applications, and
>> Apr/Oct for distributions. This helps the downstream in two ways:
>>
>> * People writing applications that depend on Zeta have a reliable
>> schedule they can work with ("I know feature X will be there in
>> February 2011"). They also have enough time to update their
>> application to use the latest library before distributions ship
>> * If we want to have Zeta in distributions, then each
>> Ubuntu/Fedora/whatever release will have a fresh Zeta version
>>
>
> Sounds good to me :)
>
> --
> Jérôme Renard
> http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard
>
