[Uim] Towards 1.0

[TOKUNAGA Hiroyuki]

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.


> 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).

> 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.)


Regards,

-- 
TOKUNAGA Hiroyuki
tkng at xem jp