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.
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.
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.
what do you think?
Y
Le 15/12/11 05:35, Daniel Russel a écrit :
In my understanding the things provided by periodic
software releases are:
1) a chance to fix outstanding bugs
2) a way of solving packaging and distribution problems
3) a way to avoid having people use code during major changes
4) an opportunity to apply more manual testing
5) a target time for implementation of new features
As a result of various properties of IMP discussed below, I'm not
seeing that we would much benefit from them compared to providing
given slightly better access to nightly builds. As a result, it
seems to me that effort would be better spent on keeping the day
to day state of things better (writing more nightly tests,
providing infrastructure for weekly tests of more involved things,
better automation of things etc).
The above problems addressed by released don't really apply to IMP
since
1) we don't tend to have outstanding bugs sitting around as most
bugs encountered are blocking for projects and so fixed in
relatively short order
2) these days, packaging for downloadable software is pretty
automatic
3) given the way IMP is structured as various loosely coupled
classes and modules, significant changes can be implemented as a
parallel module or class and then swapped for the old one when
ready, so we don't really have period where previously working
code is broken for a long time
4) we are add automatic tests as we think of things and through
using IMP constantly are doing more manual testing of it every day
than we would do for a release
5) people's schedules tend to be dictated by their other projects.
Features are implemented as needed for research/publications and
it is hard to get anyone to devote significant time to an external
imposed deadline.
The IMP 1.0 release was very much delayed, and by about a month
out was something that someone should probably think hard about
using instead of a carefully chosen svn build (based on bugs I
found and fixed after the release and which were never
backported). We have then had an extremely long time pass since
and pushed back the next release by months while waiting for a
couple of weeks work. We can say that we will, in the future,
devote more resources to release-related functionality, but people
will always want to spend their time on other things and I think
they are, in general, justified given the role that IMP plays.
As an alternative, we could have been providing transparent access
to builds (so you can easily figure out if the build yesterday
passed all the tests you care about and check it out or download
it with a copy and paste or a click), then we make the cost of
having people upgrade when bug fixes or new features are added.