Hi, Tony. On Jan 30, 2008 11:41 AM, Tony Wu <[EMAIL PROTECTED]> wrote: > Thanks. It will be helpful if you can give me some clue on this problem. I can provide more info on hang-up statistics before and after the commit, like Rustem does. BTW, 5-10% of Rustem's runs fails in the middle of the run after commit, while 0% fails before commit. That's the same thing I observe although I haven't exact statistics, but we could gather it in few days.
> It's true that I can revert it this time and every time in future, but > it does not solve the problem. What I want is to find the root cause > and fix it rather than worm out of. Sure, you're right. But here's the question on what should reside in the mainline trunk, and what should reside in branch or any other patchset. Last time we discussed this we came to agreement that end user should not experience functional (and as such, stability) problems with mainline trunk. I also argue that committing buggy issue into mainline and then trying to solve the problems on-the-fly is not the best user-oriented practice. It is useful for this-feature-developers, right, but it's frustrating for developers of other components, when stability of overall build is affected by this feature. I think it's generally a bad practice not to split stable/non-stable branches, even though it brings overheads for syncing the branches. So, given the perspective we are dealing with one branch, what we should choose: 1. Consider mainline as stable branch? Then we should revert your commit and maintain it as patchset, while trying to get clue what's happening. 2. Consider mainline as unstable branch? Then we should keep "probably-buggy" commit in trunk and get the things over on-the-fly. Honestly, I know how to work in (1) scheme only. Scheme (2) naturally brings up the idea to create a stable branch, because unstable branch seem to be unusable for referencing. What do you think, what should we do? Thanks, Aleksey.
