On Sep 27, 2017, at 3:21 PM, Llelan D. <llel...@thesnakepitdev.com> wrote: > >> After I finish on 2.1.2 I will look on 3.0. > Thank you for your response. I am looking forward to a Cygwin release. > If you could send me some guidelines as to the preferred manner of doing this > as was done with previous versions, I could work on it myself. The 1.10 > Cygport version compiles and packages just fine so I'll look at what was done > to that for now and try to translate it to v3.0.
Once you guys have some patches, let's have a look at them here upstream and see if we can slurp them in so that you don't have to carry them forward. What would be *awesome* is if -- assuming we get those patches slurped in upstream -- someone could provide some testing resources: 1. For each Github pull request 2. Nightly MTT testing (doesn't have to be too extensive) (I'm happy to explain the details of both of these if anyone has some resources to volunteer -- we should probably move over to the devel list, though) Specifically: the biggest problem we have is that no one in the Open MPI developer community currently develops and test on Cygwin. Hence, if/when we break stuff, we don't know it until Marco has the cycles to test and then develop aftermarket patches. Meaning: if we get patches to make Open MPI compile/work on Cygwin, those will only last until we (accidentally) break it again. But if we have continual testing and integration on Cygwin (with all of our other CI infrastructure), that *significantly* decreases the probability of us breaking Cygwin again. Or, at least, if/when we break it, we'll *know* it, and therefore we can *fix* it. Make sense? -- Jeff Squyres jsquy...@cisco.com _______________________________________________ users mailing list users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/users
