Re: Make Hudson happy was : Re: Hudson strat to p*ss me off ...
On Sun, Feb 21, 2010 at 4:23 PM, Emmanuel Lécharny wrote: > 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. A big +1 Had this thought in my mind, but the way you enthusiastically took up the things stopped me :-) if we try to fix a lot of things in 2.0, we would be rewriting a lot of code :-( The energy is better spent on 3.0 discussions, prototypes, etc etc... thanks ashish
Re: Make Hudson happy was : Re: Hudson strat to p*ss me off ...
On Sun, Feb 21, 2010 at 1:23 PM, Julien Vermillard wrote: > Sounds like you are pissed now, try to breath ;) > I'm agree for releasing 2.0 now. +1 /niklas
Re: Make Hudson happy was : Re: Hudson strat to p*ss me off ...
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 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 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
Re: Make Hudson happy was : Re: Hudson strat to p*ss me off ...
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 ? I really think that this is a great chance for a guy like me who wants to participate in development but is not very familiar with current MINA design and code. Have been following some discussions around MINA 3.0 though, would love to see that take more momentum Kiran Ayyagari
Make Hudson happy was : Re: Hudson strat to p*ss me off ...
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 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 -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: Hudson strat to p*ss me off ...
On Sat, Feb 20, 2010 at 10:59 PM, Emmanuel Lecharny 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
Re: Hudson strat to p*ss me off ...
I got Hudson running @work without a trouble for a year. Look like ASF one is overload or something like that.. If infra got bamboo or continuum or anything else installed in a stable way I'm +1 for moving. Le Sat, 20 Feb 2010 15:04:30 -0700, Jeff Genender a écrit : > It may be worth looking into whether we can use Bamboo which is much > better at CI. Its an atlassian project and I think it falls under > the usual free open source license. > > Jeff > > On Feb 20, 2010, at 2:59 PM, Emmanuel Lecharny wrote: > > > Hi guys, > > > > 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" ? > > > > 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 ! > > > > Sounds to me like "Peter and the wolf"... > > > > -- > > Regards, > > Cordialement, > > Emmanuel Lécharny > > www.nextury.com > > > > > -- Julien Vermillard Archean Technologies http://www.archean.fr signature.asc Description: PGP signature
Re: Hudson strat to p*ss me off ...
It may be worth looking into whether we can use Bamboo which is much better at CI. Its an atlassian project and I think it falls under the usual free open source license. Jeff On Feb 20, 2010, at 2:59 PM, Emmanuel Lecharny wrote: Hi guys, 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" ? 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 ! Sounds to me like "Peter and the wolf"... -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
