From: Hilmar L. <hl...@ne...> - 2010-01-15 14:46:23
|
Maybe I haven't made myself clear. Code that uses those classes *will not work*. We know that. It may compile, but it *will not work*. So I don't understand what the difference can be for the running application if we delete all code segments that we know *will not work*. How can it be better to leave that in? I'm willing to be educated here, but what I'm hearing is that there is a potentially large part of the TB2 web-application that we know does not work. Or is it a small part only? It seems to me that we don't know. I don't understand what is the benefit of going live with this. This is a show-stopper in my eyes. Either the code that doesn't work isn't needed to begin with, and then we might as well delete it, or it is needed. If it is needed, nobody has been able so far to state which functions are affected so we can't make a criticality assessment. So my rather strong vote is to investigate this to the point that we at least understand what is affected. If the problem is primarily that removing that guaranteed to be dysfunctional code simply takes up time to make everything compile again but none of it is exposed through the UI, then I can totally live with that for the release. But based on what I'm hearing we're not even close to understanding that this is the situation we are having. -hilmar On Jan 15, 2010, at 8:17 AM, Rutger Vos wrote: > I'm against doing that now, given the time constraints we're under. > > On Friday, January 15, 2010, youjun guo <you...@ya...> wrote: >> Hilmar, >> >> This code refactoring may take a week or a bit longer, should I >> proceed? >> >> >> >> Youjun >> >> >> >> On Thu, Jan 14, 2010 at 4:43 PM, Hilmar Lapp <hl...@ne...> >> wrote: >> Can we give those 7 java classes some more attention as to why they >> are needing the CIPRES framework to compile? Let's remember, we >> know for a fact that code that relies on that framework is >> guaranteed not to function. >> >> We should at least know what it is in those 7 classes that we know >> can't be functional because it needs the CIPRES framework. Leaving >> that code in there because we need it is the same as saying, there >> is code in there that we need but that we know doesn't work. I'm >> not comfortable with this. >> >> -hilmar >> >> On Jan 14, 2010, at 3:46 PM, youjun guo wrote: >> >> I checked into TreeBase code and found 7 java classes still need >> cipres framework 1.1 to compile. I suggest we keep it for now. >> >> Youjun >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently >> attracts the >> world's best and brightest in the field, creating opportunities for >> Conference >> attendees to learn about information security's most important >> issues through >> interactions with peers, luminaries and emerging and established >> companies. >> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel >> >> >> -- =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- >> informatics >> .nescent >> .org :=========================================================== >> >> >> >> >> > > -- > Dr. Rutger A. Vos > School of Biological Sciences > Philip Lyle Building, Level 4 > University of Reading > Reading > RG6 6BX > United Kingdom > Tel: +44 (0) 118 378 7535 > http://www.nexml.org > http://rutgervos.blogspot.com -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |