[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-dev] No more IMP releases?



Also on the note of making the nightly results more useful, could the test labels be made more descriptive? For me the important things are:
- for linux, what distribution and version
- for macs, what developer tools version, what mac os version, where boost and all came from, and if that is not kept up to date, when it was last updated
32 bit vs 64 bit is largely irrelevant and so could probably be dropped to save space. 

So names like:
- Fedora 16 (debug)
- Fedora 16 (fast)
- Centos 6 (debug)
- Centos 6 (fast)
- Centos 5
- Ubuntu XX
- Mac OS 10.6 with MacPorts
- Mac OS 10.6 with Fink
would be more helpful, I think. (and it would be very nice to have all those platforms tested). That way a user could look at the nightly results and get a good idea whether their platform is working.


On Dec 16, 2011, at 8:03 AM, Ben Webb wrote:

> On 12/16/11 5:08 AM, Yannick Spill wrote:
>> I agree with Daniel that we should try to be cleaner and not commit
>> things that break the whole compile process.
> 
> Of course - I don't think anybody is arguing that we should break things 
> all the time. ;) This is one reason why tests are useful - you can see 
> pretty quickly if you (or somebody else) has broken something. (On the 
> other hand, if you have a bunch of tests that don't work, it's that much 
> harder to see, because the difference between "0 failures" and "1 
> failure" is obvious, but that between "500 failures" and "501 failures" 
> is not. The IMP.isd tests are a good example here ;)
> 
>> 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.
> 
> I agree... but then again, that's exactly how we've done releases before 
> (well, except for the "without bugs" bit - that's pretty much impossible 
> - the best you can hope for is to fix most of them). Once multifit is 
> sorted out (the biggest hurdle right now) there's no reason why we can't 
> do something like that.
> 
> 	Ben
> -- 
>                       http://salilab.org/~ben/
> "It is a capital mistake to theorize before one has data."
> 	- Sir Arthur Conan Doyle
> _______________________________________________
> IMP-dev mailing list
> 
> https://salilab.org/mailman/listinfo/imp-dev