On Dec 16, 2011, at 5:08 AM, Yannick Spill wrote:
> Let me throw something in the discussion so other people say what they think also. After all, this is a collaborative project, and now's the time to hear what people want to do. > > I agree with Daniel that we should try to be cleaner and not commit things that break the whole compile process. But simultaneously, I think it's more interesting for us all to have a stable release for the following reasons: > - it has more impact, looks more serious, and does not run the risk of not working. > - it is cool for us: There are 29 modules in the $IMP/src/modules folder. Does anyone know what all of these models do? Does anyone even know what *any* of these modules do (except for their own modules, and maybe core and atom)? I don't! I'm sure rmf and parallel are super useful for me but never dared opening the folder. > I believe like Ben that a new release is a good thing because it forces us to advertise what we've been doing so far, and by advertising I just mean telling our labmates and maybe give them hints and new ideas on how to do things. While I think this is something we need to do more of, I'm not sure that releases automatically help (I don't recall too much of this on the least release). IMP-dev meetings and adding things to the change history might be a better way to do this. To start on this, there is a file, doc/history.dox where people should announce any interesting changes they make (and should look whenever they update IMP to find what changes have been made).
> Now as Daniel pointed out, we don't have much time to spend on that, so I'm suggesting the following. Why don't we set a date in a more or less short term, and decide that by then, every module should be working without bugs, and have a decent documentation and some examples. A release for which it's *not* the right time to code new neat features, but that's just like a snapshot of what can be done at the moment. I mean the shortest path to what looks reasonably like a new release, not perfect but working great. We could even do this on a per-module basis, saying that for the ISD module (for example), revision number 124567 is the good one that should be used for the new release. Once everyone has it's revision number ready, Daniel or Ben (just a suggestion) try to fix the last bugs where modules don't work together, and then we're good. Yes, I think this is the right direction. But if you push this a little further, I think you end up with what I'm suggesting. Just provide better tools to keep track of and access how well each module/class is working and then just "release" that module or class whenever it is working well. For a module, this can be done by adding a label to SVN or the docs whenever the module writer feels like it. And if the nightly results are more usefully presented, people can more easily make up their own minds about when to update.
The tricky case is when there are dependencies between modules (eg a change that changes the API used by another module). This requires update of several things at once, but, I think, could be handled as a mini-release just coordinating among the involved people.
> If we did so, I believe this would represent less than a week's work, mainly to write a documentation, so having a release in a few months should be no big deal. We could even celebrate that by having a beer party and some talks of each module writers so they run us through the examples of their modules to understand how they work. My main concern is that finding a week were more than a couple of people can work on cleaning up IMP is very difficult. and as a result is perpetually sliding. And the result is that releases tend to slide and slide and hence become rather less useful than the would otherwise be. The more frequent they are, the less the cost of missing them, and so the easier it is to not wait for someone.