On Mar 13, 2018, at 08:47, db wrote:
> On 12 Mar 2018, at 21:35, Ryan Schmidt wrote:
>> On Mar 12, 2018, at 13:56, db wrote:
>>> If not, shouldn't it, prior to accepting an updated port definition?
>> The buildbot is only engaged after a commit is in the repository master 
>> branch.
>> We have a separate system, using Travis CI, for doing test builds of updates 
>> that have been submitted as pull requests but have not yet been merged into 
>> the repository master branch. But most maintainers that are committers don't 
>> submit pull requests for their own software, they just commit directly to 
>> master, so their changes would not go through Travis.
> Then why contribute an update to a port circumventing the test build system? 
> What's the sense in that?

You're the first person, that I'm aware of, to suggest that we should restrict 
commits to master and require all contributors, including those who have 
already been vetted and given commit access, to make their contributions 
through pull requests. I'm sure there are other projects that have made such 
policies, but we haven't so far. Instead, we allow direct commits to master, 
and we encourage others to review those commits on the macports-dev mailing 
list or on GitHub.

We've only been on GitHub since late 2016. For the 10 years prior to that, we 
used a Subversion repository, and prior to that it was CVS. The only way to 
update those repositories was for a someone with commit access to commit to 
them. Many of us who were MacPorts committers during that time are used to this 
way of working and might find the additional roadblocks to our contributions 
that pull requests represent to be intrusive. In my case, I feel like I might 
finally be becoming proficient at submitting pull requests at least, but it has 
been a long and frustrating learning process for me, and one which is far from 
over; I'm still making git mistakes daily.

We've only had our Travis CI integration set up since mid-2017. I am not 
certain what its reliability is now. Often, when I've looked at a Travis 
failure log, it has turned out to be a problem specific to Travis, and not a 
reason to reject a PR. So I am not paying a great amount of attention to what 
Travis is doing at this time. It's nice that we have it, it's nice that our 
other developers like to use it to check their work before publishing it. But 
developers are already expected to check their work and verify the port 
installs on their own machines before committing or submitting a PR or patch; 
if they do that, they shouldn't see much on Travis that they didn't already 
know about.

Reply via email to