In what branch to work on a large-ish fpm feature?

[milancurcic]

@awvwgk @LKedward @urbanjost

@arteevraina and I are wondering how to best work on the preprocessing capability in the context of fpm, git, and GitHub.

1. Should we make incremental PRs against the main branch? I don't think so, as we'd be in a half-complete state for a while. For users who are checking out the latest fpm, it could be weird for example to see the preprocess syntax for the manifest, and that fpm parses it but does nothing else.
2. Should we create a feature branch on fortran-lang/fpm, e.g. preproc, and make incremental PRs against that branch? The advantage of this approach is that the preprocessing work would be visible to somebody exploring the repo (e.g. issues, PRs, branch), but it would not impose on the user as it would in the main branch.
3. Should we work in an fpm fork, i.e. arteevraina/fpm?

2 is my favorite for visibility. What do you think?

[urbanjost]

I would think 2 or 3 would work; making sure you incorporate accepted changes from the production version into yours as you proceed so they do not diverge any more than necessary. Depends on how big a change; more importantly how long a time period. That is the pros of the small incremental changes (that they do not result in a huge divergence into two separate programs); but I think as long as you incrementally merge in production changes you will prevent that problem. And that is assuming a worse-case scenario where there are many changes while you develop your changes. I was hoping the resulting treatment would build the post-processed files in a directory in build itself with different directories for different options much like the compiler options produce now; so multiple builds could proceed without collisions; assuming all preprocessing is complete the resulting files should all be plain .f90/.f files and pathnames should have all been resolved from things like pathnames in directives; but that might cause issues for Fortran INCLUDE statements. In my own old build system I do that so multiple option sets can be built concurrently and find it useful. It gets stickier for C and other languages. Good luck. So are you picturing the preprocessing being done separately from fpm, like a plug-in; or integrated directly into fpm? If done more like a plug-in model the development could proceed largely independently of fpm, which could avoid the issue (for the most part).

Optimally, for that to work I would picture the dependency engine of fpm to become a separate package itself that could be called by other plugins as well and even other applications, but that quickly becomes two concurrent projects (although long-term it appeals to me).

[awvwgk]

I would recommend strategy 1 regardless of the project size as it avoids issues with updating a fork/branch. Having smaller changes allows faster feedback and incorporation into the upstream project, however it requires more careful planning of the individual chunks to not contribute dead code or half-finished implementations.

From my observation, large pull requests from first time contributors can take very long to get merged (I can offer one of my first contributions to OSS as example: dftbplus/dftbplus#314) and have a significant failure rate. Therefore, I would advise against option 2 or 3.