On Fri, Jul 11, 2014 at 10:58 AM, Stas Malyshev <[email protected]> wrote:
> Hi! > > > mentioned a few times now), and I think this will cause a significant > > amount of pain for the people who wanna merge pull requests after the > > phpng (or other similar major rewrite) is merged to the master, as they > > will be required to backport the changes. > > When we will have the major rewrite merged (if it will be merged into > master at all and not used as separate branch), we'll deal with it, but > it didn't happen yet, so I was talking about the situation now. > I would be pretty surprised if we would have a branch for PHP-next, but that wouldn't be merged into master. > > Right now I think we should use the same model many other projects use > to run development - that is, one active development branch (master) and > stable branches where patches are merged into on one-by-one basis. I think we are pretty unique in the sense that we have at least 4 active development branch at any given time (oldstable, stable, nextstable, master). > This > is also a workflow described here for features: > https://wiki.php.net/vcs/gitworkflow I guess you are referring to https://wiki.php.net/vcs/gitworkflow#feature_workflow_for_core_developers That is just an example for explaining how to use git with the feature branches workflow. For example the next section ( https://wiki.php.net/vcs/gitworkflow#workflow_for_external_contributors) uses the PHP-5.4 as the base for the fork/PR and only mentions using master as the base as an option. > > > > Ofc. when we have a diverging master we can't really save the porting, > > but we could offload that work to the PR authors, and porting forward is > > better documented (UPGRADING.INTERNALS) than porting backwards. > > Right now it is not needed since master is not that different. I've already seen Pull Requests which were cleanly apply for master but merging it into the "correct" branch caused conflicts, and as we merge that upwards, it could even conflict again when reaching the branch which introducted the divergence. > When it'd > be needed you'd probably need separate pulls for both branches anyway, > since the porting effort may be significant. > Yeah, I also think that. > > If you need to test your patch on multiple branches, you also can always > fork on gihtub and hook Travis CI to your private fork, and run the > builds on those too. Running CI does not require a pull. > Ofc, no argument here. I was just pointing out that introducing the requirement to always target master will probably require more work from the people doing the merge, and given how few people actually doing that I think it would make sense to shift that to the person opening the PR instead of the one merging it. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
