Updated work flow for sims_maf_contrib

[rhiannonlynne]

Hi all,

We've been experimenting with various workflows for adding code to sims_maf_contrib (or rather - we didn't actually have anything particular in mind, and various people have done various things).

We had a rather alarming incident yesterday with a force-push to master. Please note - you should never have to force-push under normal use. What this does is force the remote repository to look exactly like your local copy (including the commit history, and deleting files that don't exist or weren't committed in your copy of the repo), and should only be done in some very specific circumstances. We have recovered from this force-push, although if you had commits you pushed between April 5 and April 9, please talk to me as they likely have been lost. I have also put protections in place to guard against this in the future; we should have had those in place earlier.

As a result of these changes, however you may notice that you cannot push directly to master anymore.

I would like to more carefully continue to experiment with workflows for adding code to sims_maf_contrib, and suggest that in the future we only add code to sims_maf_contrib master via pull requests.

This means that you can either fork the repo, develop on your fork, and then issue a PR to lsst-nonproject/sims_maf_contrib, or you can create a branch, develop on your branch, and then issue a PR to master.

If this seems problematic, let me point out that this will have a couple of advantages:

• first of all, when your code is added to the master branch of sims_maf_contrib, everyone will be able to see when and how the code came into the repository, via the PR. You can link an issue to the PR, to add more conversation about what is going on in the code changes. You can also have a 'conversation' associated with the PR. Have a look at Eric Bellm's nice issue and PR related to GRBTransientMetric for an example: #30 and #31
• secondly, going through the PR stage will help us catch any problems that may exist with the code that could create problems down the road with MAF compatibility, and we can offer gentle suggestions to help improve the code. We promise not to be sticklers about style, formatting, and will not be judging you on your code -- it's basically an extra set of eyes to help look out for any possible problems. Code reviews have consistently proven to be the best way to improve a code base - and you want your code to be reusable by other people and maintainable in the future, two things which can be helped by this process.

Please let me know if you have any concerns about this new workflow. We need to have something that will work for all of us, and I think this will be a sizeable improvement.

Lynne