Hi Thorsten, On Thu, 08 Feb 2007 at 17:55 +0000, Thorsten Glaser wrote: > Waldemar Brodkorb dixit: > > >Make a lokal change and use it for your systems for some weeks, if > >you report no problems, we can think of a switch. > > Just for the archives: several developers suspected my gcc patches > to be responsible for the recent breakage. I knew they weren't, > because I have not only tested the difference between with/without > them, but also tested them locally first. Yes, both of them (the > -fhonour-copts and the integer overflow fix patch). Also, I had > tested these changes in MirBSD gcc 3.4.6 (i.e. almost the same > version) first - the -fhonour-copts diff since 31 January 2006, > the overflow fix naturally not so long but I nevertheless did > _two_ full (BSD) kernel+userland builds with it before applying > the fix to FreeWRT, testing on FreeWRT and committing there. > > [EMAIL PROTECTED] dixit: > > >Log: > >merged busybox upgrade to 1.4.1 from branch > >more testing needed! > > When I read commit messages like this one, without the intent > to merge being communicated by mail or IRC, especially the "more > testing needed" part, I can't help but remember the ADK merge > which broke trunk, because it was not tested enough. I'd like to > have a "careful merge" policy (even careful commit) to keep trunk > breakage low - true, we're all making typos and committing these > by accident, but if someone is merging in a branch, I expect the > branch to work first.
Yes, in a perfect world I would agree to this. Unfortunately we are not in a perfect world and everybody make a lot of mistakes every day. Time is critical, i invested a lot of time and money into FreeWRT, this can only work for me in the future if some of my plans work out properly. For that I need to have things done in a given timeframe. To reach this goal I sometimes decide to push in changes earlier and without testing. If the code does not get into trunk, nobody will test it and the next release will be very bad. I decided in a personal mail to Markus, that he should merge back the busybox branch. Furthermore I decided Phil should merge back the common-adk branch. So if you need to complain about these decisions, please just call me, and I explain you in detail why I still think this was the best solution. > Same for toolchain stuff - e.g. gcc or binutils. Even if it does > appear to work, wbx@ is right when he wants you to test it for > a while without committing it. (It's not that hard, you have the > 'M' in your tree, and 'svn st' shows it, but it won't prevent > other operation.) Even better, communicate to wbx@ and ask him > to test the diff on a few more boxen. As far as I know, he's got > several exemplars of all supported targets exactly to make this > happen. Sure, I have a lot of playing hardware just for verifying bugs on different hardware. > Regarding the ADK merge: I remember having said I'd like to > test e.g. the contents of the .ipk files against before the > merge first. True, I wasn't physically there when the merge > was done, because I overslept, totally my fault, but I have > said that before. What shocked me more is that ADK did build > but not boot on even one single target before it was merged > back in. I know exactly how bad trunk is tested, even before the merge nobody has used it. If you would try to at least follow 50 % of our meetings you could had avoid this. But as you said, it was your fault. So do not complain, but fix bugs. Why I wrote such a long mail? Take the short answer: "shut up and hack!" > Errors are made so that we can learn from it. This is not a > flame mail. I hope we all have had our lesson(s). bye Waldemar -- don't open your wrt, free it http://www.freewrt.org _______________________________________________ freewrt-developers mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-developers
