harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [classlib]remove the duplicate locale data
Date Wed, 30 Jan 2008 11:09:05 GMT
On 1/30/08, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> Hi, Tony.
> On Jan 30, 2008 11:41 AM, Tony Wu <wuyuehao@gmail.com> 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.
Frankly I've have no idea on the error log posted on Harmony-5435. I'm
not sure what kind of test/tool Rustem is running. Just want to
confirm with you, I've run specJBB2005 and get the report successfully
for 5 times. Highly appreciate if there is further infomation.

> > 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 believe the trunk is for developer not for end user, correct me if
I'm wrong.  I can not imagine that an opensource project asks their
end user to try their trunk directly, just the other way, they may
claim that the trunk is not a stable version and suggest the user to
download the release version. Probably that's the different opinion
among us :)

> 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?

I think we have been working with the second way. Otherwise, what does
the Milestone build stand for? We create a tag as M4 and claim it is a
stable verion, we may ask user to try M4 and continue our development
on trunk. That's wyh I happy to revert my patch last time for assuring
the stability of M4.

In the contrast, if we use the trunk as a stable verion. We may need
to create many branches to guarantee that. How to manage the
synchronization from trunk to branch and how to make sure that the
branch is stable enough to be merged back to trunk? Shall we set up a
BTI for every branch? What a mess if everything goes to be that way.

> Thanks,
> Aleksey.

Tony Wu
China Software Development Lab, IBM

View raw message