[Uim] Towards 1.0

[YamaKen]

At Thu, 18 Aug 2005 07:17:39 +0900,
tkng at xem.jp wrote:
> 
> On Fri, 12 Aug 2005 12:04:59 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> > At Wed, 10 Aug 2005 04:37:34 +0900,
> > tkng at xem.jp wrote:
> > > 
> > > On Tue, 09 Aug 2005 07:32:54 +0900
> > > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > 
> > > > I only want 3 sequencial unstable snapshot release from 0.5
> > > > around merging the r5rs branch, as follows.
> > > > 
> > > > 1) Make an unstable release from 0.5 series immediately before
> > > >    merging r5rs branch into the trunk
> > > > 
> > > > 2) Make another unstable release from 0.5 once the merger has
> > > >    become roughly stable
> > > 
> > > IMHO this phase should be done in r5rs branch.
> > 
> > No. What I intended by 2) is not the SigScheme migration itself
> > in r5rs branch but merging it into trunk.
> 
> Before the merger, trunk and r5rs should be synced except for SigScheme
> related code. If not, we should merge them. Therefore, merging r5rs to
> trunk will be only copying of SigScheme related code. Status of these
> branches right after merger must be synced completely. If r5rs branch
> is stable, then trunk is also stable, because both of them should share
> same code completely.

I know. What you said is the "it will cause no problems within
an ideal situation" I said. But whether the syncing between the
two branches is complete or not is not the problem for me.

What I want about 2) is only stepping following process. You are
not required to recognize my worry.

- merge r5rs branch into trunk
- check that the trunk is working as same as latest r5rs branch
- release an unstable release from *trunk* (not from r5rs)

Are you feeling some problems about doing this steps?

> > Yes, it will cause no problems within an ideal situation. But as
> > you already know, my pessimistic thought distinguishes the two.
> > 
> > The words "the merger has become roughly stable" is supposing
> > about resolving conflicts, logical code glitches, unexpected
> > duplicated lines caused by excessive or incomplete diff lines
> > passing between the branches until the time, etc.
> > 
> > But I'm not requesting a paranoiac process. What I want by 2)
> > are simply defined as:
> > 
> > - merge r5rs branch into trunk
> > - check that the trunk is working as same as latest r5rs branch
> > - release an unstable release from *trunk* (not from r5rs)
> > 
> > > > 3) Make more another unstable release from 0.5 at 10 days (or 2
> > > >    weeks if patient) after from 2).
> > > > 
> > > > The trunk must be kept unchanged other than r5rs branch merging
> > > > through the days between 1) and 3). This is required to reject
> > > > unstabilizing factors came from other than the SigScheme
> > > > migration.
> > > > 
> > > > Expected benefits are:
> > > > 
> > > >   - The two milestone releases 1) and 3) will become reference
> > > >     points to be compared with subsequent 0.5 series about its
> > > >     behaviors, to locate where a bug comes from
> > > > 
> > > >   - 3) will become new origin which the composer branch based
> > > >     on. I'll forward-port it to the branch
> > > 
> > > I agree basically.
> > 
> > Thank you.
> > 
> > > I have one question. 3) is intended to be only be a origin of
> > > new composer branch? 
> > 
> > No. 3) is needed for all people, to judge whether a bug came
> > from the SigScheme migration or not.
> 
> That would be possible with 2).

If no bugs arose after 2).

You can see 2) as a release candidate. So you can re-release 2)
as 3) if no bugs arose.

I assume that bugs will appear regardless of actual quality of
the product.

So I planed as if 2) is a buggy release and 3) will solve the
problems based on feedbacks from testers. It's an popular
development process to guarantee a quality.

in Japanese:
私は実際の製品の品質にかかわらず、バグは現れるものだと仮定してい
ます。それゆえ私は2)がバグ持ちリリースで、3)が試用者からのフィー
ドバックに基づいてそれを解決するものとして計画しました。品質を保
証するためのありふれた開発手順に過ぎません。

> > 1) and 3) are expected as:
> > 
> > - 1) will become the most stable code before introducing
> >   SigScheme. It is a "reference point" ("kijun-ten" in Japanese)
> > 
> > - 3) will become the mostly stable code based on SigScheme. It
> >   is another "reference point"
> > 
> > If you release the 1) and 3) as I suggested, any people can find
> > where a bug came from, when an user find a buggy behavior on the
> > trunk beyond 3). I refer this point as 4).
> > 
> > - If 1) shows the buggy behavior, the bug ware hiding before 1)
> > 
> > - Otherwise, if 1) does not show the bug and 3) shows, the bug
> >   came from the SigScheme migration
> > 
> > - Otherwise, if 3) does not show the buggy behavior, the bug
> >   is inserted between 3) and 4)
> > 
> > Comparing a behavior between some reference points is a popular
> > and efficient method to locate a wrong point ("shougai no
> > kiriwake" in Japanese).
> > 
> > > If so, I think trunk freezing between 1) and 2) is sufficient.
> > 
> > In addition, 2) is intended to be tested by active users
> > enough. And of course stability feedbacks from them is also
> > intended.  So I insert the interval (10 days - 2 weeks) between
> > 2) and 3). The interval gives them one or two weekend to examine
> > it.
> 
> Of course 2) should be tested by active users. But I don't understand
> the necessity to stop trunk for 10 days after 2). I want to know an
> example of trouble which is difficult to solve without freezing
> of trunk. (But if the example is too long, I don't need. In such case,
> please write only 'Certainly such case exists.' I'll believe and freeze
> trunk.)

3) is expected to be the well-stabilized primary reference point
for the problem location process in a future. So 3) must not
contain any code not related to the SigScheme migration.

If 3) contain a code other than bugfix for the migration, it
will appeared as a logical noise when we comparing 1) and 3) in
the process, and we will be bothered unnecessarily. And of
course it will also be an unstabilizing factor.

We shouldn't do two things in same time as you said.

in Japanese:
3)は将来において問題発生点を突き止める作業のために、よく安定した
一等基準点である事が期待されています。それゆえ3)はSigSchemeへの
移行に関連しないいかなるコードも含むべきではありません。

もし3)がSigScheme移行のバグ修正以外のコードを含んだ場合、それは
問題発生点を突き止める作業において1)と3)を比較する際に論理的ノイ
ズとして現れ、我々はいらない面倒を負うでしょう。そしてもちろん不
安定化要因にもなります。

あなたの言ったように、我々は2つの事を同時にすべきではありません。

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp