This should beg the question (this may already be answered, so I apologize if I am out of the loop) - when we make changes to SIPNET code to suit a particular research question, by what process should we decide to merge those changes into the code repository? Should we all comment on the blog, and if we all say "yes - that would be helpful for us all", then merge appropriately? While I know we are all doing good things with SIPNET, running all these parallel threads might not match well when merged together in the repository (it has happened before), potentially losing the "SI" in SIPNET.
Can we come to a consensus on a "core" SIPNET model? I am not well-versed enough in programming to know what would the appropriate code-development scheme would be to all of our multiple research threads. I don't think having branches from the repository with our own code tweaks would be useful - it seems that we would have multiple copies of very similar code. Maybe a sort of "plug - in" scheme, where each thread has a few base files that are plugged into the model, and maybe supersedes conflicting code. That way it could be easier to distinguish between all our different changes.
Subscribe to:
Post Comments (Atom)
Bill's response:
ReplyDeleteI think you raise some good points, particularly about the distinction between changes that are really just useful for your own specific project (best kept in a branch of the repository) and changes that will be generally useful (and are best merged back into the trunk of the repository, at least at some point).
My own feeling on this is that things will go most smoothly if there is a single person designated as keeper of the code. That person would be the one to approve merges back into the trunk, to ensure that things don't get too chaotic. Unfortunately I don't have time to serve in that role right now myself.
Ankur's response:
ReplyDeletePlus someone needs to write the iPhone version of SIPNET!
There isn't a good way to do this. Personally, we should all write branches off the main version and once a year or so, merge accepted changes (with compiler or other flags to turn on/off features). But yes - it requires a keeper of the code.
Not it.
yes - some things are going on in the branches and it might be useful
ReplyDeleteto know what they are so that people can make progress more quickly.
>
> This should beg the question (this may already be answered, so I apologize
> if I am out of the loop) - when we make changes to SIPNET code to suit a
> particular research question, by what process should we decide to merge
> those changes into the code repository? Should we all comment on the blog,
> and if we all say "yes - that would be helpful for us all", then merge
> appropriately? While I know we are all doing good things with
> SIPNET, running all these parallel threads might not match well when merged
> together in the repository (it has happened before), potentially losing the
> "SI" in SIPNET.
Sadly we have no process right now ... I think Bill's idea of a benign
dictator is right.
We can't lose the SI cause then we'd be back at PNET and that might be
confusing.
> Can we come to a consensus on a "core" SIPNET model? I am not well-versed
> enough in programming to know what would the appropriate code-development
> scheme would be to all of our multiple research threads. I don't think
> having branches from the repository with our own code tweaks would be useful
> - it seems that we would have multiple copies of very similar code. Maybe
> a sort of "plug - in" scheme, where each thread has a few base files that
> are plugged into the model, and maybe supersedes conflicting code. That way
> it could be easier to distinguish between all our different changes.
I think the branches are the best way to go for most adjustments. We
should all be sensitive to the idea that merging with the main trunk
should happen once a year. I agree with Ankur - there should be
switches in the code to allow things to be turned on and off
My vote for what the core code is:
The version used in John's paper in Ecosystems. Roots, Microbes etc
can be easily switched on and off.
I also vote for the Zobitz et al., (Ecosystems) version and I agree with Ankur in that once a year or so, we should compare all our branches and "someone" can act as the Swiss guard of the repository. I've been using the Zobitz version (hence my vote :-] )
ReplyDelete