Hi guys,
After making another commit into my ucwords() pr and waiting for an hour or so I noticed that Travis CI hasn’t picked it up yet; in fact, the previous commit wasn’t picked up either.
Other pr’s that were created before or after mine were processed, though.
Is this a known issue? It would be nice to have the added confidence of a passing test suite before merging changes :)
On Fri, Jul 11, 2014 at 9:22 AM, Tjerk Meesters tjerk.meesters@gmail.com
wrote:
Hi guys,
After making another commit into my
ucwords()pr and waiting for an hour
or so I noticed that Travis CI hasn’t picked it up yet; in fact, the
previous commit wasn’t picked up either.Other pr’s that were created before or after mine were processed, though.
Is this a known issue? It would be nice to have the added confidence of a
passing test suite before merging changes :)
Hi,
https://travis-ci.org/php/php-src/requests
tells me that
9074897bc6a5a3 https://github.com/php/php-src/commit/bc6a5a3-Added
support for ranges like trim() hasPull requestbranch not included or
excluded
And while I was trying to figure out what does that mean, or why should
that prevent the travis build, I've just remembered that we don't allow
travis builds for PHP-5.3 and PHP-5.4 branches:
http://git.php.net/?p=php-src.git;a=blob;f=.travis.yml;h=f1a333adcb3e6c35f3fe19c27fbd7a28d99fe7de;hb=refs/heads/PHP-5.4
So probably it is because of that.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
And while I was trying to figure out what does that mean, or why should
that prevent the travis build, I've just remembered that we don't allow
travis builds for PHP-5.3 and PHP-5.4 branches:
http://git.php.net/?p=php-src.git;a=blob;f=.travis.yml;h=f1a333adcb3e6c35f3fe19c27fbd7a28d99fe7de;hb=refs/heads/PHP-5.4
So probably it is because of that.
All feature pulls should be done against master only. They will be
merged to appropriate branch but as pulls it should always be master
unless it is a fix specific to particular version.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
On Fri, Jul 11, 2014 at 10:29 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Hi!
And while I was trying to figure out what does that mean, or why should
that prevent the travis build, I've just remembered that we don't allow
travis builds for PHP-5.3 and PHP-5.4 branches:So probably it is because of that.
All feature pulls should be done against master only. They will be
merged to appropriate branch but as pulls it should always be master
unless it is a fix specific to particular version.
Theoretically you are right, that until a PR is merged, one cannot be sure
which branch will it end up in.
But I don't think we have an official rule about that this (albeit you
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.
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.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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.
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. This
is also a workflow described here for features:
https://wiki.php.net/vcs/gitworkflow
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. When it'd
be needed you'd probably need separate pulls for both branches anyway,
since the porting effort may be significant.
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.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
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 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
Hi!
Hi!
And while I was trying to figure out what does that mean, or why should
that prevent the travis build, I've just remembered that we don't allow
travis builds for PHP-5.3 and PHP-5.4 branches:
http://git.php.net/?p=php-src.git;a=blob;f=.travis.yml;h=f1a333adcb3e6c35f3fe19c27fbd7a28d99fe7de;hb=refs/heads/PHP-5.4
So probably it is because of that.All feature pulls should be done against master only. They will be
merged to appropriate branch but as pulls it should always be master
unless it is a fix specific to particular version.
I see, though I would have the same issue if this was a fix instead of a feature, right? :)
In any case, I reasoned that it would be easier to start at the lowest version where this feature could peacefully coexist and then merge it up to 5.5, 5.6 and finally master.
Should I do this in another way then? :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/