Re: Merge from 5.3 and/or 5.4. What's the current policy?
| From: | Yasuo Ohgaki | Date: | Fri, 30 Mar 2012 09:43:38 +0000 |
| Subject: | Re: Merge from 5.3 and/or 5.4. What's the current policy? | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-59228@lists.php.net to get a copy of this message | ||
Hi
2012/3/30 Pierre Joye <pierre.php@gmail.com>:
> hi,
>
> On Fri, Mar 30, 2012 at 10:22 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> Bug fix can be merged upwards. However,
>> Are we free to merge feature changes?
>
>
> Generally speaking, no.
I thought so.
>
>> Adding new module constant is new feature.
>
> Not necessary, for example in Curl or openssl, many constants addition
> do not change the implementation per se. But it has to be discussed
> from a case by case basis.
>
>> Before git, we just commit new feature/changes
>> to trunk and we could think/argue about merge
>> later. Now we need to think/argue about merge,
>> then commit.
>
> Right, and that's actually very good. The commit first then try to
> discuss is finally over.
For large changes, discussing first is good.
For small changes like this, it may be too much.
>
>> We need some guidelines for feature changes,
>> if we are going to keep "merge upward" policy.
>
>> Anyway, RM of 5.3/5.4 are okay to add module
>> constants to pgsql? If there is no objection, I'll
>> commit the change and updates docs.
>
> RMs apply the developers decisions, in general. So please post your
> proposals to the list, CCing them :)
https://gist.github.com/2250214
The change is simple one.
Just making constants available defined in pg-config.h
The only reason why I've made this thread for this simple
change is "merge upward" policy.
Someone suggested gitflow, the flow would be better for
faster development.
--
Yasuo Ohgaki
yohgaki@ohgaki.net