Sounds like you are pissed now, try to breath ;) I'm agree for releasing 2.0 now.
Julien Le Sun, 21 Feb 2010 11:53:28 +0100, Emmanuel Lécharny <[email protected]> a écrit : > Ok, guys, > > sorry for my overreaction... > > Sure we have to check what's going on with the builds. > > If we look at the build history, we see that we don't have that many > failures. The problem is that those failures seems to be > time-dependent. The JDK 1.6/Windows build are also in constant > failure, and it has to be fixed. > > Looking at som of the failures, I'm a bit annoyed : the failing tests > are totally cryptic, I'm not able to know what is being tested. I > would say, considering MINA's history, I'm not suprised. At some > point, it's difficult to say if : > - the test is broken > - the part which is tested is broken but nobody uses it and should be > removed > - or we have a serious issue > > In any case, for anyone who crawl into the mud^H^H^Hcode it's pretty > obvious that MINA design is far from being extracted from any blue > print. Yesterday I had a look at the IoSession hierarchy, and once > agin, it's totally broken. We have generic used to express the fact > that the IoProcessor is typed, but it's not consistent, and to avoid > a compilation error, the top level processor variable does not use > generic. Also we don't have a processor varibale in the > AbstractIoSession, the place it should be. We don't have either the > getProcessor() method in the interface, and I can't move it there as > the API is frozen now. > > What I want to say is : get this bloddy 2.0 out, and let's bury it. > It's dead code, it's a cancer we can't fix. Any time we spend on it > is a waste, and slow down our work on MINA 3.0. > > We have some issues like DIRMINA-764, but it can be worked around on > the client side, and can't be fixed on the server without fixing the > whole mess and breaking the API. I suggest we stop here, unplug the > monitor and oxygen, and move to the next version. > > Thoughts ? > > On 2/21/10 9:31 AM, Niklas Gustavsson wrote: > > On Sat, Feb 20, 2010 at 10:59 PM, Emmanuel > > Lecharny<[email protected]> wrote: > >> is there any reason why this stupid Hudson *always* fail when we > >> commit some new code, and one hour later come back with again 6 > >> useless mails telling us that "Hey, sorry, I was totally f*cked up > >> last time I sent you 6 mails" ? > > I don't think that is entirely correct. We're running four builds > > for trunk (Ubuntu with Sun JDK 1.6, Ubuntu with Sun JDK 1.5, > > WIndows with Sun JDK 1.6, WIndows with Sun JDK 1.5). These get > > reported separately and might run at different times (due to how > > they are scheduled and the current job queue in Hudson), therefore > > the different builds might report their results at different times > > during about one hour (we poll SVN once per hour). > > > > One the the builds, on JDK 1.6 on Windows, consistently fails on one > > of the MDC tests. I reported that on this list about a week ago but > > I have not had the time to look into the details myself: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-windows/org.apache.mina$mina-core/14/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/ > > > > > >> If Hudson can't inform us when there are *real* errors, at some > >> point, we will simply ignore the alerts and lose all interest of > >> having Hudson as a safety belt ! > >> > > I'm pretty sure that on most occasions Hudson is reporting the real > > errors and that we should look into why the builds fail (like the > > one on Windows). > > > > That said, I've found a some builds in the last weeks where there > > seems to be inconsistencies in the results. Some of these are also > > worth looking into. Here are those I've found: > > * Build creating corrupt JAR, Maven problem?: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-windows/9/ > > * Maven failed to install JAR, Maven problem?: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.6-ubuntu/226 > > * One-time test failure in XBean module: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-windows/7 > > * Hudson problem, possibly due to the MINA build getting killed by a > > restart of Hudson: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-ubuntu/7/ > > * One-time test failure in core: > > http://hudson.zones.apache.org/hudson/view/MINA/job/MINA-trunk-jdk1.5-ubuntu/6/ > > > > So, I think our time is better spent at looking at why our tests > > fail, which will reduce the number of failed builds in Hudson (or > > any build tool) and thus the email frequency. > > > > /niklas > > > > > > -- Julien Vermillard Archean Technologies http://www.archean.fr
signature.asc
Description: PGP signature
