Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75371
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53BFA72B.1080008@sugarcrm.com>
References: <2264B27B-F9BE-4540-AD1C-5046143F18D2@gmail.com>
	<CAH-PCH6bDLvEdcSH-Vt7WkDs8WHfqhghUoW55bG2zaesNSOg6w@mail.gmail.com>
	<53BFA075.9000201@sugarcrm.com>
	<CAH-PCH4mH5LDGZ2SJu7YEQytw8E6WAKwM4bFZ-6NPa4D5LDgdA@mail.gmail.com>
	<53BFA72B.1080008@sugarcrm.com>
Date: Fri, 11 Jul 2014 11:45:48 +0200
Message-ID: <CAH-PCH62p5_haogmkdBQ3QjVpJCvmjSKb5iWaKj9HUGbY8JDLQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Tjerk Meesters <tjerk.meesters@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134f152622fa404fde7cea7
Subject: Re: [PHP-DEV] Travis CI for pull requests
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a1134f152622fa404fde7cea7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 11, 2014 at 10:58 AM, Stas Malyshev <smalyshev@sugarcrm.com>
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 i=
s
> > 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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a1134f152622fa404fde7cea7--