Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: The RFC is about integrating O+ into PHP which can by definition only happen in 5.5 and later. Implicitly no, while it is clear that it has to be done. But explicitly the RFC uses the word integration for 5.5 and it won't happen. However what is voted on is: Integrate into 5.5, even if minor delay required Integrate into 5.5 only if it's not delayed, otherwise - 5.6 Don’t integrate Optimizer+ to PHP And what will actually happen if accepted is bundlingcleanup for 5.5, integration in 5.6 or later. That makes a rather huge difference, especially when it is about delaying 5.5 for a relatively unknown period. It is even more disturbing as the gain between that and having it in PECL for the meantime is very very low. A real integration (at least partially) may be done it during the beta phases but I very much doubt that it is feasible, stabilize it will likely take more time and beginning to do many changing to actually integrate o+ into core is way too risky during beta/RC phases. The essential questions being asked by the RFC are whether to delay 5.5 for it, no delay and wait until the next version, or don't integrate at all the last of which implies external-only distribution either through pecl or individual distros simply packaging it from Github. Distros will distribute it as separate packages anyway, I do not really the point here. And your beef about integration vs. bundling is rather nit-picky. No, it is not. Hence why I asked to have the roadmap (no date but a plan and actual actions listed) to have an informed vote. The first step towards integration is getting it in. That does not guarantee that further steps can be done, from a timely manner. How much integration is done will depend on what people come up with. I have a pull request in for at least one level of integration that will allow it to save a stat call by integrating more closely with the sapi layer to save that initial stat if the sapi layer can pull it from the server layer. That is more than mere bundling, but it should also be rather safe to do. That is done in APC already. Any extensions can use it, being in core or not. What we do about earlier versions is a completely separate and mostly unrelated issue. There is no real reason not to support those via pecl, but that isn't what this RFC is about. And, like you say, there is nothing stopping you or anybody else from making a pointer to it from pecl. I agree, it is a separate issue. However it does affect the decision about delaying 5.5 for it while everything do or add can be done via pecl. That's why I think everything should be part of the RFC so voters can take an informed decision based on the actual planed moves. The question about little 5.4 adoption because of the lack of opcode cache support does not apply to 5.5 and o+ as it already supports quite well, minus the remaining issues (see Matt's post earlier this week). But again, I am not trying to stop o+ being in core, but the contrary. Almost all our (my team colleagues) resources are on testing 5.5 and o+ (and APC too as a fallback). We also provided patches, use cases, etc. we discovered or implemented while testing 5.3/4/5 and o+ with our tests benchmarks. My only point is the actual gain to delay 5.5 even more without knowing when we can release it, shooting in the dark and the lack of PECL support for previous php versions (as in: won't reduce our work load because we will still have to support APC as a prio #1 for 5.3/4). Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On 03/03/2013 12:43 AM, Pierre Joye wrote: On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: The first step towards integration is getting it in. That does not guarantee that further steps can be done, from a timely manner. There is never any such guarantee and the current results of the vote clearly says that the majority of people are fine with a delayed 5.5 release. How much integration is done will depend on what people come up with. I have a pull request in for at least one level of integration that will allow it to save a stat call by integrating more closely with the sapi layer to save that initial stat if the sapi layer can pull it from the server layer. That is more than mere bundling, but it should also be rather safe to do. That is done in APC already. Any extensions can use it, being in core or not. So? It is not done in O+. The fact that APC is better integrated on this particular point doesn't invalidate this as a low-hanging fruit integration step for O+. And there are other such low-hanging fruits we are likely to find, test and deem stable enough to get into 5.5. What we do about earlier versions is a completely separate and mostly unrelated issue. There is no real reason not to support those via pecl, but that isn't what this RFC is about. And, like you say, there is nothing stopping you or anybody else from making a pointer to it from pecl. I agree, it is a separate issue. However it does affect the decision about delaying 5.5 for it while everything do or add can be done via pecl. That's why I think everything should be part of the RFC so voters can take an informed decision based on the actual planed moves. The question about little 5.4 adoption because of the lack of opcode cache support does not apply to 5.5 and o+ as it already supports quite well, minus the remaining issues (see Matt's post earlier this week). But again, I am not trying to stop o+ being in core, but the contrary. No, but you are certainly trying to delay it by suggesting that the current RFC needs to be rewritten and presumably voting restarted at which point you can shout louder about how much this is delaying the 5.5 release because you will have added a month of purely process time to the mix. The fact is that the current release managers support delaying the release on the chance that we can get a stable opcode cache into this release and there is decent majority support for this approach according to our own process however faulty it may be, so I would ask you to stand down and let us do our thing instead of getting in the way. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Sunday, March 03, 2013 9:26 AM To: Zeev Suraski Cc: Laruence; PHP Developers Mailing List Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski z...@zend.com wrote: How Don't integrate Optimizer+ to PHP can be remotely related to the available of o+ via PECL? Actually it seems as if some of the original text got lost when I switched to the active vote, but it used to read 'Don't integrate Optimizer+ to PHP, release only in PECL'. My bad. No offense and pls do not see what I will say here as an attempt to block it, as I really want o+ in core. I think this RFC should be fixed (fix wording to represent the actual actions, s,integration,bundlingcleanup,), votes options added to cover what has been discussed. Add a roadmap as well for the further steps that can/could/will be taken to make o+ even better while being in core. Pierre, The whole 'integration' point is well defined in the RFC under the 'PHP 5.5.0 section'. There's no tight integration on the table. The delay is also defined as anywhere between 0 and 1-2 months, it's not open-ended. I added a bit of clarifying text to the 3rd option, to ensure people understand this would mean we make it avail through PECL. I'm not going to add additional voting options at this point. Look around, the a strong majority of devs and the vast majority of core devs wants it in 5.5.0, and not continue hashing with bureaucracy. We'd really love to be done with the discussion instead of restarting it. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel
On Sat, Mar 2, 2013 at 7:07 PM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: On 3 March 2013 07:48, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, Jan 17, 2013 at 8:18 AM, PHP Group gr...@php.net wrote: rasmus approved ardbiesheuvel account request \o/ Are you a different guy from abies (with an @ewi.tudelft.nl address)? Credited as the author of Firebird/InterBase driver for PDO Interbase... The abies account is still active.. Yes, that is me. I didn't realize the old account was still active after all these years. Do you still have access to that email address ? We should probably try to migrate your accounts, so if you still have access to that email address you can reset your password at https://master.php.net/forgot.php and I'll merge your karma (if there is any difference) and delete your new account... Sounds good? If you'd like to change your username to your new one we can delete your old account and merge your karma (if there is any difference) to your new accounts and delete the old account.. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow (...)-foo() expressions not only for `new`
Hi
- usage expression in write context (e.g. passing constant by reference)
function foo($foo) {}
foo(abc[0]);
- destruction of temporary result
($a . $b)[4]; // if ($a.$b) is destroyed?
- in some cases destruction of temporary result may cause destruction of
final result
((object)(array(a=b)))-a = c; // temporary object may be destroyed
before assignment
I've run a bunch of examples like above, with debug enabled, and so far
I could find no scenario where it would leak or access destructed
variable. So looks like it works, at least I wasn't able to find any
case where it does not :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel
On 3 March 2013 18:08, Hannes Magnusson hannes.magnus...@gmail.com wrote: If you'd like to change your username to your new one we can delete your old account and merge your karma (if there is any difference) to your new accounts and delete the old account.. I am fine using the new account. If there is a need to merge the karma, please do so but I think the new account has all the karma I need. Regards, Ard. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel
On Sun, Mar 3, 2013 at 3:25 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: On 3 March 2013 18:08, Hannes Magnusson hannes.magnus...@gmail.com wrote: If you'd like to change your username to your new one we can delete your old account and merge your karma (if there is any difference) to your new accounts and delete the old account.. I am fine using the new account. If there is a need to merge the karma, please do so but I think the new account has all the karma I need. You can't really have two open accounts.. Few *random* reasons for that would be; - Since we employ seriously crazy strict voting system on every single change, you currently have two votes.. - You can pretend to be a 6years old using one accounts and destroy out system, get your karma revoked, and then do it all again on your other accounts - Code reviewing / commit validation is more difficult. I'll delete your old account, if for no other reason then just because I can :) Let me know if you hit any issues :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel
On 3 March 2013 12:36, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Mar 3, 2013 at 3:25 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: I am fine using the new account. If there is a need to merge the karma, please do so but I think the new account has all the karma I need. You can't really have two open accounts.. Few *random* reasons for that would be; - Since we employ seriously crazy strict voting system on every single change, you currently have two votes.. - You can pretend to be a 6years old using one accounts and destroy out system, get your karma revoked, and then do it all again on your other accounts - Code reviewing / commit validation is more difficult. I'll delete your old account, if for no other reason then just because I can :) Let me know if you hit any issues :) As I said, I am fine using the new account, so sure, go ahead and delete the old one. Regards, Ard. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel
On Sun, Mar 3, 2013 at 3:38 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: On 3 March 2013 12:36, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Mar 3, 2013 at 3:25 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: I am fine using the new account. If there is a need to merge the karma, please do so but I think the new account has all the karma I need. You can't really have two open accounts.. Few *random* reasons for that would be; - Since we employ seriously crazy strict voting system on every single change, you currently have two votes.. - You can pretend to be a 6years old using one accounts and destroy out system, get your karma revoked, and then do it all again on your other accounts - Code reviewing / commit validation is more difficult. I'll delete your old account, if for no other reason then just because I can :) Let me know if you hit any issues :) As I said, I am fine using the new account, so sure, go ahead and delete the old one. Thanks! I've deleted the old account now and removed his karma (your new account already has more karma then the previous user anyway). If something got fuckedup, or you need to verify your previous username on various social media services (github, ohloh, whatever).. let me know and we'll figure something out! -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow (...)-foo() expressions not only for `new`
On Tue, Feb 26, 2013 at 6:08 PM, Dmitry Stogov dmi...@zend.com wrote:
On Tue, Feb 26, 2013 at 8:49 PM, Nikita Popov nikita@gmail.comwrote:
On Tue, Feb 26, 2013 at 7:41 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Nikita,
I like the idea.
But note, that it may cause some unexpected behaviour and bugs.
I didn't test the patch I just guess it on my previous experience
introducing similar features.
- usage expression in write context (e.g. passing constant by reference)
function foo($foo) {}
foo(abc[0]);
- destruction of temporary result
($a . $b)[4]; // if ($a.$b) is destroyed?
- in some cases destruction of temporary result may cause destruction of
final result
((object)(array(a=b)))-a = c; // temporary object may be
destroyed before assignment
All these edge cases must be carefully analyzed.
I like the current patch, and in case the edge cases won't require many
hacks, I'm all for it.
Thanks. Dmitry.
I just played a bit with it and came up with the following (additional)
patch to support use in write context:
https://github.com/nikic/php-src/commit/31705dd8c53efe3bb52d6aae483a324e5a511ae9It
throws an error if the write is done on a TMP or CONST,
I like this patch more (it doesn't complicate executor).
This patch is on top of the other one, so the executor changes still apply.
This one is only about write-context, but the executor optype changes were
necessary for read-context (as in read-context CONST/TMP are valid, unlike
in write context).
However it doesn't handle BP_VAR_FUNC_ARG, where decision about read/write
context must be done at run-time.
Good catch, I didn't consider that one (didn't even know it exists ^^).
This would require a few more changes:
https://github.com/nikic/php-src/commit/6f5483f006794dc78f8c341b1a6d7ad18c2e56be
Nikita
[PHP-DEV] NEWS file rename
Hi, I've just renamed the NEWS files to a branch specific variant. NEWS files should not be merged up (as their contents are not linked) and they always cause a bit pain when doing automated things (such as the tzdb update). cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
On Sun, 03 Mar 2013 20:00:47 +0100, Derick Rethans der...@derickrethans.nl wrote: Hi, I've just renamed the NEWS files to a branch specific variant. NEWS files should not be merged up (as their contents are not linked) and they always cause a bit pain when doing automated things (such as the tzdb update). How does that fix anything? You'll still have a conflict because you'll be changing a file that doesn't exist in the other branch. Besides, the solution is well documented on the wiki: https://wiki.php.net/vcs/gitfaq#mandatory_git_settings -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PCRE 8.32 upgrade
Hi, I've merged PCRE 8.32 into the current dev branches. The test pass so far on all the constellations in Windows and Linux. However it'd make sense to observe it with more attention in the next builds. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
Hi! I've just renamed the NEWS files to a branch specific variant. NEWS files should not be merged up (as their contents are not linked) and they always cause a bit pain when doing automated things (such as the tzdb update). I would really prefer first asking, then doing things to stable repos. And NEWS merging is working just fine in git, what exactly is the problem with that? We have special hooks in place just for that, and I have never seen any problem with them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
On Sun, 3 Mar 2013, Stas Malyshev wrote: I've just renamed the NEWS files to a branch specific variant. NEWS files should not be merged up (as their contents are not linked) and they always cause a bit pain when doing automated things (such as the tzdb update). I would really prefer first asking, then doing things to stable repos. And NEWS merging is working just fine in git, what exactly is the problem with that? We have special hooks in place just for that, and I have never seen any problem with them. Everytime I want to merge up from PHP-5.3 to 5.4 to 5.5 to master for the timezone database I get conflicts in NEWS, I don't even touch that file. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
On Sun, 3 Mar 2013, Gustavo Lopes wrote: On Sun, 03 Mar 2013 20:00:47 +0100, Derick Rethans der...@derickrethans.nl wrote: I've just renamed the NEWS files to a branch specific variant. NEWS files should not be merged up (as their contents are not linked) and they always cause a bit pain when doing automated things (such as the tzdb update). How does that fix anything? You'll still have a conflict because you'll be changing a file that doesn't exist in the other branch. Maybe, but right now it frustrates me every time. Besides, the solution is well documented on the wiki: https://wiki.php.net/vcs/gitfaq#mandatory_git_settings Yeah, right. That is not a solution, but a hack. NEWS should just be outside of GIT at all as you can not rely on everybody having that hack in their config. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
Hi! Everytime I want to merge up from PHP-5.3 to 5.4 to 5.5 to master for the timezone database I get conflicts in NEWS, I don't even touch that file. Did you set up git as described in https://wiki.php.net/vcs/gitfaq#mandatory_git_settings ? Because I never had merge conflicts in NEWS, it shouldn't be even possible with this setup... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
On Sun, 3 Mar 2013, Stas Malyshev wrote: Everytime I want to merge up from PHP-5.3 to 5.4 to 5.5 to master for the timezone database I get conflicts in NEWS, I don't even touch that file. Did you set up git as described in https://wiki.php.net/vcs/gitfaq#mandatory_git_settings ? Because I never had merge conflicts in NEWS, it shouldn't be even possible with this setup... I have never seen that, but I do consider that a hack. You will never get everybody to make that configuration. Feel free to revert it. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
Hi! I have never seen that, but I do consider that a hack. You will never get everybody to make that configuration. Feel free to revert it. Well, I think it works reasonable well (it did for me). It is a hack, but it gets the job done and it's pretty easy. Maybe it has to be more visible or if there's some way of integrating it in the repo (like .gitignore) it'd be excellent, but my git knowledge is not enough for that. David, any ideas how to make this easier? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
On Sun, Mar 3, 2013 at 10:18 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I have never seen that, but I do consider that a hack. You will never get everybody to make that configuration. Feel free to revert it. Well, I think it works reasonable well (it did for me). It is a hack, but it gets the job done and it's pretty easy. Maybe it has to be more visible or if there's some way of integrating it in the repo (like .gitignore) it'd be excellent, but my git knowledge is not enough for that. David, any ideas how to make this easier? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I suppose we could use a .gitattributes file: http://blog.mindlesstechie.net/2012/08/17/always-keep-your-copy-of-a-particular-file-in-a-git-merge/ -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] NEWS file rename
Hi! I suppose we could use a .gitattributes file: http://blog.mindlesstechie.net/2012/08/17/always-keep-your-copy-of-a-particular-file-in-a-git-merge/ You still have to do git config with this solution. The whole problem is that not everybody knows that it needs to be done. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
hi Derick, On Sun, Mar 3, 2013 at 8:00 PM, Derick Rethans der...@derickrethans.nl wrote: Hi, I've just renamed the NEWS files to a branch specific variant. NEWS files should not be merged up (as their contents are not linked) and they always cause a bit pain when doing automated things (such as the tzdb update). Commit first and then ask (well, inform us in this case...) is not going to work very well. About this issue, there are different problems to solve. If developers does not setup his git correctly, then we have to make the points listed in the FAQ more visible. Maybe on www as well, or at least a link with Please configure git correctly as described in Also not only NEWS should be there but the various UPGRADING files as well. That's something you would notice as soon as you implement new things. I'd to agree on one thing tho'. NEWS should not be manually edited. With or without git, it is a (relatively small) pain. Back to the git migration time, David and I discussed about generating it from the commit messages. That implies to enforce a commit message format, a 1st attempt is described here: https://wiki.php.net/vcs/gitworkflow#new_commit_message_format. The RMs could then call a script to generate it on release. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
On Sun, Mar 3, 2013 at 10:12 PM, Derick Rethans der...@php.net wrote: On Sun, 3 Mar 2013, Stas Malyshev wrote: Everytime I want to merge up from PHP-5.3 to 5.4 to 5.5 to master for the timezone database I get conflicts in NEWS, I don't even touch that file. Did you set up git as described in https://wiki.php.net/vcs/gitfaq#mandatory_git_settings ? Because I never had merge conflicts in NEWS, it shouldn't be even possible with this setup... Feel free to revert it. Huh well... Apparently not a lot of people like this change, if one has to do it then you :-) Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
Hi! I'd to agree on one thing tho'. NEWS should not be manually edited. With or without git, it is a (relatively small) pain. Back to the git migration time, David and I discussed about generating it from the commit messages. That implies to enforce a commit message format, a 1st attempt is described here: https://wiki.php.net/vcs/gitworkflow#new_commit_message_format. The RMs could then call a script to generate it on release. Commit messages themselves won't be very useful - a fix could include a number of commits, and people regularly write commit messages not in format suitable for NEWS. I'd rather prefer them to put it in NEWS file - where they have an example of how it's done right, and where they can put it in proper order, proper sections, etc. It won't save much work because if people would neglect to do it with NEWS file, they'd also neglect to put messages in commit in proper format, so they will have to be hand-edited anyway. So we don't win much by telling people not to bother about NEWS anymore - I'd rather have them to bother with it and make RM's life a bit easier. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEWS file rename
On Mon, Mar 4, 2013 at 7:23 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I'd to agree on one thing tho'. NEWS should not be manually edited. With or without git, it is a (relatively small) pain. Back to the git migration time, David and I discussed about generating it from the commit messages. That implies to enforce a commit message format, a 1st attempt is described here: https://wiki.php.net/vcs/gitworkflow#new_commit_message_format. The RMs could then call a script to generate it on release. Commit messages themselves won't be very useful - a fix could include a number of commits, and people regularly write commit messages not in format suitable for NEWS. I'd rather prefer them to put it in NEWS file - where they have an example of how it's done right, and where they can put it in proper order, proper sections, etc. It won't save much work because if people would neglect to do it with NEWS file, they'd also neglect to put messages in commit in proper format, Well, we could write a pre commit script and reject commits with invalid messages, hard but fair :) Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
