harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [build-and-test] Update: plan for improving of the new testing infra before switching to it.
Date Tue, 24 Apr 2007 03:13:09 GMT
On 4/23/07, Nathan Beyer wrote:
> I would just suggest tagging the trunk (make a copy of trunk with a
> well-defined name in the  tags folder), and do whatever you want to do
> with the trunk, it's supposed to be the current development line. In
> addition, I would suggest, adjusting the published docs to point to
> this tag to check out the infrastructure. However, if there's any plan
> on continued maintenance, then create a branch, tag off that, point
> the docs to check out the tag.
> If we're not very sure about this "2.0" code, then I would create a
> branch for it "2.0-dev", then once it's ready, tag the trunk as 1.0
> and then merge(replace?) the 2.0 code into the trunk. This is exactly
> what 'branches' sub-folders are for, maintenance and disruptive (to
> the trunk) current development.
> It seems silly to create a pseudo-branch under the trunk folder, as
> the whole point of the branches/tags/trunk folder is for working like
> this. If we don't want to work like that, then dump the whole
> convention.
> Let's stop avoiding good SCM practices and embrace them. In the case
> of buildtest, just work with the caveat that "releases" are directly
> checked out, instead of downloaded from an alternate location.

Thanks Nathan! Your suggestion and arguments sound reasonable for me.
I'm going to create a new branch for 2.0 infra version.


> -Nathan
> On 4/23/07, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> > Hi,
> >
> > I'd like to give an update about current status of buildtest infra.
> > Currently we have the proposal [1] for the infra improvement, its
> > implementation [2] and several testing suites that use the proposed
> > approach. I think that the proposed infra is not quite ready to do the
> > switch - I've reviewed the implementation and tried 4 suites with it;
> > I've found several issues and I see some places where it can be
> > improved. And I believe that the issues should be resolved before
> > switching to the new testing infra.
> >
> > To make further progress I think it makes sense to commit the
> > implementation from [2] to SVN as it is. And continue development and
> > bug fixing in SVN. This will make improvement process more
> > transparent, for example, currently there is tenth version of
> > 'btinfra.zip' file and it is not possible to figure out what have
> > changed since its first version.
> >
> > I'm not sure that a new branch should be created to check in the new
> > infra. I think it may be acceptable to create sub-directory in trunk,
> > say 'v2.0'. And continue the infra development and new suites
> > integration there. After we find that the new infra in a good shape we
> > can do the switch.
> >
> > Opinions?
> >
> > [1] http://mail-archives.apache.org/mod_mbox/harmony-dev/200703.mbox/%3ce09a11790703262343m576dee90j5a59d52e14290274@mail.gmail.com%3e
> > [2] http://issues.apache.org/jira/browse/HARMONY-3501
> >
> > Thanks,
> > Stepan Mishura
> > Intel Enterprise Solutions Software Division

View raw message