On Mar 10, 2016, at 12:48 AM, Mojca Miklavec wrote:

> On 10 March 2016 at 05:48, Ryan Schmidt wrote:
>> 
>> Obviously nobody is going to commit something they believe is broken, but it 
>> does sometimes end up being the case for some subset of users. When it does, 
>> and we learn that it has happened, we try to fix it. If everybody had to 
>> test everything on a clean system on every version of OS X and every version 
>> of Xcode before committing, nobody would ever commit anything because nobody 
>> has the time and resources to do all that testing. We do have automated 
>> build machines that do build every commit on a clean system with no ports 
>> installed with several versions of OS X and the latest version of Xcode for 
>> those systems. That automated system did catch this webkit2-gtk build 
>> problem on El Capitan,
> 
> 
> When I was testing wxWidgets, discovered a problem and submitted a
> patch, I noticed what they are doing now (which is some light years
> more advanced compared to what they did a few years back when most of
> the tickets were stuck ignored at their Trac; similar to what happens
> in many cases in MacPorts).
> 
> - user submits a patch
> - the system checks whether the patch applies cleanly
> - the system automatically builds wxWidgets on Windows in 6 different
> ways (cygwin, mingw32 with msys, mingw, nmake with VS 14, nmake with
> VS 9, msbuild), on Linux in five different ways (one is with clang
> 3.5), and on OS X 10.9
> - I'm not sure whether wxWidgets does it as well, but it is also
> possible to run tests as part of the build
> 
> The developers then only apply the patch if all of the checks mentioned pass.
> 
> The point is that this is all done *in advance* and avoids a lot of
> problems. I would love to see something similar being done for patches
> submitted to our Trac. Of course they would have to be submitted in a
> different way and I'm aware that this is not really trivial to set up.
> But it would be extremely helpful.

Yes, this would be helpful. I intend to look into doing something like this. 
However right now and for the next several weeks there are a lot of other more 
pressing issues I need to be working on for Mac OS Forge.



_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to