On 13 Mar 2018, at 15:22, Ryan Schmidt <ryandes...@macports.org> wrote:
> 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.

Thanks for the background. I don't know how much inconvenience would that mean 
for developers, I do know as a user though. I suppose that problems would be 
properly caught in the pipeline and almost never make it to the user. Skipping 
it because of being inconvenienced, that doesn't make any sense whatsoever to 

Reply via email to