harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [testing] test exclude list: can't we have incremental exclusions?
Date Fri, 24 Nov 2006 20:01:48 GMT
24.11.06, Geir Magnusson Jr.<geir@pobox.com> написал(а):
>
>
> Alexey Varlamov wrote:
> > Geir,
> > This was a bit emotional maybe... Sure, any way it will be is not
> > lethal, and I do not mind it too much.
>
> What, the veto?  I didn't take it that way :)  My point was that when
> someone puts up a "-1", it really gets people's attention as a strong
> position.
>
> > My point is if you modify "official" x-list you most certainly won't
> > lose it off track, while local svn-ignored file have a good chance to
> > hang around for a while. OTOH, is there any difference which file to
> > edit? I suppose no, hence this is almost useless in my POV.
>
> I agree you won't lose it, but when it's in a file that isn't meant for
> purely personal use then you have problems in being sure not to commit
> it, having to deal with merge conflicts, etc.
>
> I think about it in the same spirit of the drlvm.properties.example -
> people copy to an un-svn-ed local copy for local config.  Excluding
> tests while you are working on something is that kind of thing.
Nope - drlvm.properties fixes stable state of things, you set it and
forget it; most merging conflicts are just bothering fuss.
Excluding tests should be momentary and ideally not happening at all,
so some minor inconveniences may be paying here. And even merging
conflict should justly draw your attention - maybe your modification
is not that local.

>
> > If you really want it, I've withdrawn my veto.
>
> No :)  I'd like to come to consensus.  You may even convince me it's not
> a good idea.
>
> I think that maybe one solution that may address your concerns would be
> to actually put the file under SVN!  Then
>
> a) you'll notice when there's something in it - the state of the file in
> SVN should always be empty
>
> b) If you forget and commit, someone can flag it.

This would also solve that problem with non-existing file.
But, now this adds even less value - the only difference from
mainstream x-lists is somewhat lesser chance for conflicts :).

>
> geir
>
> >
> > --
> > Regards,
> > Alexey
> >
> > 24.11.06, Geir Magnusson Jr.<geir@pobox.com> написал(а):
> >> As a point of process, ball is on your court.  I'm respecting your -1
> >> (although I wouldn't personally have been so forceful with a veto - and
> >> I'm not sure that this is really something that can be vetoed), but I
> >> expect us to discuss...
> >>
> >> geir
> >>
> >> Geir Magnusson Jr. wrote:
> >> >
> >> > Alexey Varlamov wrote:
> >> >> Geir,
> >> >>
> >> >> This sounds alarming - why do you need local exclude list?
> >> >
> >> > Because I may be testing something and I dont' want that test to be run
> >> > for some reason.
> >> >
> >> >> This is
> >> >> error prone, you might forget about locally excluded tests and then
> >> >> commit improperly tested.
> >> >> -1 until convincingly useful.
> >> >
> >> > People are going to do it anyway - comment out things locally.  If I
> >> > screw up, and mask something, then everyone else is going to find my
> >> error.
> >> >
> >> > I see no danger to this, and we make people's lives easier.
> >> >
> >> > geir
> >> >
> >> >
> >> >>
> >> >> --
> >> >> Alexey
> >> >>
> >> >> 24.11.06, Geir Magnusson Jr.<geir@pobox.com> написал(а):
> >> >>> And while you're at it, how about making kind-and-gentle support
for
> >> >>> local excludes such that I can have a file
> >> >>>
> >> >>>     exclude.local
> >> >>>
> >> >>> which is my local exclusion list that
> >> >>>
> >> >>> a) will be svn-ignored and
> >> >>>
> >> >>> b) doesn't have to be there - so if a developer hasn't created
the
> >> file,
> >> >>> the build just keeps going...  I *think* that not having the file
> >> for an
> >> >>> <excludesfile> entry will let the build keep going, but I'm
not sure.
> >> >>>
> >> >>> geir
> >> >>>
> >> >>>
> >> >>> Geir Magnusson Jr. wrote:
> >> >>> > That works for me.  It will only increase the number of files
if
> >> >>> > platforms have bugs, but it will make for easier maintenance.
> >> >>> >
> >> >>> > We'll do the same in DRLVM too.
> >> >>> >
> >> >>> > geir
> >> >>> >
> >> >>> > Ivanov, Alexey A wrote:
> >> >>> >> Hi everyone,
> >> >>> >>
> >> >>> >> Recently test exclude lists were removed from build.xml
of the
> >> >>> >> corresponding module, and there were added *six* files
with
> >> excluded
> >> >>> >> tests. These files contain almost the same list of files.
The
> >> lists
> >> >>> >> are identical for swing module. I found 2 differences
for awt
> >> module
> >> >>> >> (there are still about 50 files names listed in every
of the
> >> exclude
> >> >>> >> lists).
> >> >>> >>
> >> >>> >> Why can't we use one 'exclude.all' file to exclude tests
which
> >> >>> fail on
> >> >>> >> every platform? It's an obvious optimization.
> >> >>> >> I've tested the approach of using several exclude list
files on
> >> >>> >> build.xml of swing module. It works just fine.
> >> >>> >>
> >> >>> >> Your comments?
> >> >>> >>
> >> >>> >> Regards,
> >> >>> >> Alexey.
> >> >>> >>
> >> >>> >>
> >> >>> >> ----- build.xml patch --------
> >> >>> >> Index: build.xml
> >> >>> >>
> >> ===================================================================
> >> >>> >> --- build.xml   (revision 478584)
> >> >>> >> +++ build.xml   (working copy)
> >> >>> >> @@ -186,6 +186,7 @@
> >> >>> >>
> >> >>> >>                  <fileset
> >> dir="${hy.swing.src.test.api}/java/common">
> >> >>> >>                      <include name="**/*Test*.java"/>
> >> >>> >> +                       <excludesfile name="./make/exclude.all"
/>
> >> >>> >>                      <excludesfile name="${exclude.file}"
/>
> >> >>> >>                  </fileset>
> >> >>> >>              </batchtest>
> >> >>> >> ------------------------------
> >> >>> >>
> >> >>> >>
> >> >>> >> --
> >> >>> >> Alexey A. Ivanov
> >> >>> >> Intel Enterprise Solutions Software Division
> >> >>>
> >>
>
Mime
View raw message