> > Maybe it would be better to start by submitting one PR for one isolated > port. We can then give you feedback on anything that might need to be > changed and merge it. This may enable you to make similar changes in your > other ports before submitting them. Then submit a PR for a second port. At > some point, once your PRs are getting accepted with no changes, you could > submit two or more ports together in a single PR, if the ports are similar > and not too complex >
Actually I already started the process more than a week ago. The first library, Partio, was accepted and merged yesterday: https://github.com/macports/macports-ports/pull/7006 But of course, Open Shading Language (OSL), the library that depends on Partio, failed the Travis CI build, since Partio didn't exist in the ports tree when I submitted it at the same time: https://github.com/macports/macports-ports/pull/7007 This is what prompted me to write my original question, because it seems that a piece of software like Blender which has a complex dependency tree could potentially take weeks or months for all of the new libraries to get accepted into MacPorts. But the general consensus seems to be to submit each library individually, so I suppose that's the path I'll have to take. -- Jason Liu On Tue, May 12, 2020 at 8:11 PM Ryan Schmidt <ryandes...@macports.org> wrote: > > > On May 12, 2020, at 12:44, Jason Liu wrote: > > > I would like to contribute a portfile for the newest version of Blender. > I already have a local portfile that is compiling successfully, and I am > doing some cleanup before submitting a pull request on GitHub. In addition > to Blender itself, I have also packaged several of Blender's dependent > libraries, which would also be new ports. My question is: Would it be > better for me to submit all of the portfiles for Blender and the libraries > in one single pull request? Or should I submit one pull request for each > new package individually? > > > > The reason why I ask is that the dependency tree is a bit complex, with > some of the libraries dependent on other libraries which I packaged as > well. And if I were to submit each of the libraries individually, there's > no telling how long it would take to get each one of them accepted and > merged before I would be able to submit the Blender portfile. > > > Thanks for contributing! And thanks for asking first. > > A problem I've seen before is that someone will submit a bunch of new > ports or port updates all at once and make the same "mistakes" in each of > them. Maybe not exactly mistakes, but doing things that are not necessarily > the way we would recommend. It then becomes tedious to supply the same > feedback for each port. We have many best practices that we'd like ports to > follow and not all of them are well documented. Some of them just need to > be learned by experience. > > You may also want to let the earlier ports go through the buildbot system > first to see if there are any build problems, especially on the older OS > versions that the continuous integration systems hooked up to our pull > requests don't test. > > Maybe it would be better to start by submitting one PR for one isolated > port. We can then give you feedback on anything that might need to be > changed and merge it. This may enable you to make similar changes in your > other ports before submitting them. Then submit a PR for a second port. At > some point, once your PRs are getting accepted with no changes, you could > submit two or more ports together in a single PR, if the ports are similar > and not too complex. > > I agree with others that a "commit bomb" that adds very many new ports all > at once or makes very many changes all at once is likely to get ignored > because it's just too much to review all at once, and mistakes are more > likely to get overlooked. > >