It wouldn't be a bad idea to open bug or a feature requests to be
able to
specify multiple locations for versioning report and mirror/comparator
task.
Off the top of my head, I don't recall us doing anything special in
the
past the one time we had similar situation. And, off the top of my
head,
both the "versioning report" and the "comparator" are all designed
to work
against one drop location and one repo (respectively).
There might be some way to "hand edit" the reference.xml file to
replace
Dali entries from SR2 with your release from December ... but ...
not sure
how easy that would be, and might be error prone. [And, Carl, maybe
that's
what you were asking me about via IM and I misunderstood?].
But, if its just versioning problems for immediate (M6) you want to
find,
it would probably be easiest to do a 'find' or directory listing of
what
interests you, sort it (to make compare work better), pipe it to a
text
file, and then do a diff compare of December version to M6 version.
Eclipse "compare with each other" function works pretty good at
highlighting significantly different parts. I hate to admit the
number of
times I have used this approach to compare directory listings :)
The versioning report (from memory) still (partially) uses
old-fashioned
directory listings etc., not the repo meta data (though, I'm
working on
such a thing ... its been side lined). I think the versioning
report would
be the hardest one to fix, since I think part of it reads "what is in
currently running version" (e.g. during JUnit testing) and compares
that to
the reference ... but ... all pretty fuzzy all these years later.
But my
guess is the versioning report, as it is now, would likely take
more work
to fix ... a little "redesign" or something ... not impossible ...
but,
more like a week or two of effort (just to guess) ... and it if
does just
use the old fashioned "directory" approach, I'm not sure its worth
fixing,
IMHO. Better to focus on one that uses repo metadata.
The comparator issue, [In addition to what Carl said in his reply
... ] if
there was one, is a bit different. In one way worse, in one way
better. The
better aspect, is if there is an "error or warning" then I think it is
still a legitimate "error or warning", of some sort, since it only
"looks
for errors or warnings" when the versions/qualifiers all match
exactly.
[But, as Carl said, lots of "spurious ones" right now.] The worse
aspect,
the comparator is ran as part of a p2.mirroring operation that says,
basically, if versions and qualifier match exactly, then take the
older one
since should be the same content, but it then runs the comparator
to make
sure it it is same content. So, this is "bad" in the sense that its
not
giving the right level of protection as if it was ran against the
"correct"
December release. Such as, you might have a version now, in M6,
that "is
the same" as December's, but "newer" than Indigo SR1, so ... we'd
still be
ending up with the newest one ... but, not the more comparable
version from
December ... and that'd only be a problem if there really _is_ a
difference
in content now, from December, even though the version/qualifier
are the
same ... so as is, there is no "check" to test or see that.
Relatively rare
problem. But ... would be good to fix before the "release", I would
not
think it is a "blocking problem" unless you are seeing some
concrete that
looks real weird.
The mirror/comparator tasks would (likely) be the easiest to fix
--- its
just in the builder ... near the final "packager" tasks, I believe
-- could
probably use multiple reference repos for what it was mirroring
(and even
then, when I say "easy" I mean possibly 1 to 4 full days of effort).
HTH
From: Neil Hauge<neil.hauge@xxxxxxxxxx>
To: wtp-releng@xxxxxxxxxxx,
Date: 03/15/2012 01:09 PM
Subject: Re: [wtp-releng] Smoke Test Request for WTP 3.4.0 I-build
towards WTP 3.4.0
Sent by: wtp-releng-bounces@xxxxxxxxxxx
Chuck, Carl, and others,
I've realized that the current versioning report isn't giving us an
accurate picture of Dali's plugin and feature version correctness.
The
reason being that we released 3.1 in December, but the reference
build in
the resport is the most recent maintenance build, which for us
doesn't give
us the right reference.
I can't remember what we did in this scenario the last time we did an
off-cycle release, but perhaps David or Tran remembers how we
handled this
with regards to version reporting. Perhaps we ran an ad-hoc report
against
the Dali release reference build?
Currently, I think we have some versions that need to be updated to
distinguish themselves from the 3.1 versions. Also, I noticed
there were a
large number of unexpected comparator errors in this build. We
generally
require this list to be clean for an M build, correct?
Neil
On 3/15/2012 12:26 PM, Chuck Bridgham wrote:
Smoke Test Request for WTP 3.4.0 I-build towards WTP 3.4.0
Please document your Project's testing and approval of this
build,
by noon(EST) Friday, or let us know if that's not possible.
Current Build
http://build.eclipse.org/webtools/committers/wtp4x-R3.4.0-I/20120315123754/I-3.4.0-20120315123754/
Smoketest Results
http://wiki.eclipse.org/WTP_Smoke_Test_Results_R340_03152012
Thanks - Chuck
Senior Architect, RAD Java EE Tools, WTP PMC Lead
IBM Software Lab - Research Triangle Park, NC
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
