[PATCH] Add sequence number to 'xm info'

[PATCH] Add sequence number to 'xm info'

[Dan Smith]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

This patch causes the short changeset id or sequence number to be
included on the 'xen_changeset' line in the 'xm info' output.

We plan to use this sequence number as a very fuzzy way of sorting
test reports so that we can start looking for trends.  While we know
it won't result in a perfect ordering of changesets for reporting, it
will help us get close.

Signed-off-by: Dan Smith <danms@us.ibm.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: changeset.patch --]
[-- Type: text/x-patch, Size: 1004 bytes --]

diff -r 5e5ae8340956 xen/Makefile
--- a/xen/Makefile	Wed Sep 28 20:06:49 2005
+++ b/xen/Makefile	Wed Sep 28 15:07:14 2005
@@ -99,7 +99,7 @@
 	    -e 's/@@version@@/$(XEN_VERSION)/g' \
 	    -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
 	    -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
-	    -e 's!@@changeset@@!$(shell (hg parents | awk -F: '/^changeset/{CS=$$3};{FS="date:[ ]+"}/^date/{D=$$2}; END {print D, CS}') 2>/dev/null || (head -n 6 ChangeLog | awk -F: '/^changeset/{CS=$$3};{FS="date:[ ]+"}/^date/{D=$$2}; END {print D, CS}') 2>/dev/null || echo information unavailable)!g' \
+	    -e 's!@@changeset@@!$(shell (hg parents | awk '{FS="changeset:[ ]+"}/^changeset/{CS=$$2};{FS="date:[ ]+"}/^date/{D=$$2}; END {print D, CS}') 2>/dev/null || (head -n 6 ChangeLog | awk -F: '/^changeset/{CS=$$3};{FS="date:[ ]+"}/^date/{D=$$2}; END {print D, CS}') 2>/dev/null || echo information unavailable)!g' \
 	    < include/xen/compile.h.in > $@.new
 	@cat include/xen/banner.h >> $@.new
 	@mv -f $@.new $@

[-- Attachment #3: Type: text/plain, Size: 87 bytes --]

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: [PATCH] Add sequence number to 'xm info'

[Ian Pratt]

 
> This patch causes the short changeset id or sequence number 
> to be included on the 'xen_changeset' line in the 'xm info' output.
> 
> We plan to use this sequence number as a very fuzzy way of 
> sorting test reports so that we can start looking for trends. 
>  While we know it won't result in a perfect ordering of 
> changesets for reporting, it will help us get close.

I guess for trees that are direct clones of xenbits with no local
modifications then the short id is meaningful. Such trees are probably
in the majority.
It does feel slightly distateful to be including such an id, even though
I can see the point (I wrote the regex deliberately to strip it out). I
guess it doesn't really hurt providing people know what they're doing.

Ian

Re: [PATCH] Add sequence number to 'xm info'

[Dan Smith]

IP> I guess for trees that are direct clones of xenbits with no local
IP> modifications then the short id is meaningful. Such trees are
IP> probably in the majority.  

Indeed.  Additionally, people who are testing xen on all of their
systems will most likely be doing so with a real clone of the repo,
and not one with a bunch of random patches, I would think.

IP> I guess it doesn't really hurt providing people know what they're
IP> doing.

I think the people who don't know what they're doing won't know that
it's not part of the larger changeset ID, which means they'll copy the
whole thing when posting a bug, which gets the info there anyway.

Would it be better to tuck the sequence number away somewhere else?  I
think that would be a bit overkill, but if anyone has strong feelings
about it, I can do it.  Perhaps adding "xen_build" to "xen_major" and
"xen_minor"?

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com

Re: [PATCH] Add sequence number to 'xm info'

[Hollis Blanchard]

On Sep 28, 2005, at 5:35 PM, Dan Smith wrote:

> This patch causes the short changeset id or sequence number to be
> included on the 'xen_changeset' line in the 'xm info' output.
>
> We plan to use this sequence number as a very fuzzy way of sorting
> test reports so that we can start looking for trends.  While we know
> it won't result in a perfect ordering of changesets for reporting, it
> will help us get close.

So if the new format is
	xen_changeset          : Wed Sep 28 13:06:49 2005 +0100 
7120:5e5ae8340956
This is a bad idea. If you want to compare two changesets, you already 
have the full date right in front of you!

The revision number is a convenience for *local* operations, for 
example 'hg export 7033:7035'. It obviously should never be compared 
across different repositories "and just hope things work out ok."

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [PATCH] Add sequence number to 'xm info'

[Sean Dague]

[-- Attachment #1.1: Type: text/plain, Size: 1972 bytes --]

On Thu, Sep 29, 2005 at 10:45:32AM -0500, Hollis Blanchard wrote:
> On Sep 28, 2005, at 5:35 PM, Dan Smith wrote:
> 
> >This patch causes the short changeset id or sequence number to be
> >included on the 'xen_changeset' line in the 'xm info' output.
> >
> >We plan to use this sequence number as a very fuzzy way of sorting
> >test reports so that we can start looking for trends.  While we know
> >it won't result in a perfect ordering of changesets for reporting, it
> >will help us get close.
> 
> So if the new format is
> 	xen_changeset          : Wed Sep 28 13:06:49 2005 +0100 
> 7120:5e5ae8340956
> This is a bad idea. If you want to compare two changesets, you already 
> have the full date right in front of you!
> 
> The revision number is a convenience for *local* operations, for 
> example 'hg export 7033:7035'. It obviously should never be compared 
> across different repositories "and just hope things work out ok."

Yes, single repository, like xen-unstable (upstream).  For the xm test work
having a sequence number from a single repo makes a number of things much
easier.  If it was so harmful to have the sequence number then I would think
it would be eliminated from hg entirely.

Most people using hg for xen-unstable aren't doing so to write code, they
are doing so to make it easy to test latest pull (akin to anon cvs).  For
that class of people and applications, having sequence number available is a
very good thing.

	-Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] Add sequence number to 'xm info'

[Dan Smith]

HB> +If you want to compare two changesets, you already have the full
HB> +date right in front of you!

That's true.

HB> The revision number is a convenience for *local* operations, for
HB> example 'hg export 7033:7035'. It obviously should never be
HB> compared across different repositories "and just hope things work
HB> out ok."

I completely agree and understand.  Telling someone to try to resolve
their problem by checking out changeset 7033 would be a bad idea.
However, if we're talking about loosely grouping and sorting a month's
worth of test reports to make a determination about failure trends, I
think it's a valid way to do it.  It's quick and it doesn't require
any parsing of the date string.

Also, when I'm comparing two of my test machines to see which is
running a newer pull, I have to parse the date string with my eyes and
do timezone conversions to figure out the order.  Since my (and most,
I imagine) test machines are always running clones of the main repo,
the sequence numbers would always be valid.

Independent of how people choose to use the information, is there a
strong argument for not even showing it?

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com

Re: [PATCH] Add sequence number to 'xm info'

[Hollis Blanchard]

On Thursday 29 September 2005 11:02, Sean Dague wrote:
> On Thu, Sep 29, 2005 at 10:45:32AM -0500, Hollis Blanchard wrote:
> > On Sep 28, 2005, at 5:35 PM, Dan Smith wrote:
> > >This patch causes the short changeset id or sequence number to be
> > >included on the 'xen_changeset' line in the 'xm info' output.
> > >
> > >We plan to use this sequence number as a very fuzzy way of sorting
> > >test reports so that we can start looking for trends.  While we know
> > >it won't result in a perfect ordering of changesets for reporting, it
> > >will help us get close.
> >
> > So if the new format is
> > 	xen_changeset          : Wed Sep 28 13:06:49 2005 +0100
> > 7120:5e5ae8340956
> > This is a bad idea. If you want to compare two changesets, you already
> > have the full date right in front of you!
> >
> > The revision number is a convenience for *local* operations, for
> > example 'hg export 7033:7035'. It obviously should never be compared
> > across different repositories "and just hope things work out ok."
>
> Yes, single repository, like xen-unstable (upstream).  For the xm test work
> having a sequence number from a single repo makes a number of things much
> easier.  If it was so harmful to have the sequence number then I would
> think it would be eliminated from hg entirely.

The revision number is useful, as you can see in my export example above -- 
there would be no easy way to specify a range of changesets without it.

> Most people using hg for xen-unstable aren't doing so to write code, they
> are doing so to make it easy to test latest pull (akin to anon cvs).  For
> that class of people and applications, having sequence number available is
> a very good thing.

I haven't seen Dan's intended use case described, but there are better sources 
of information, such as the changeset hash or the changeset date.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [PATCH] Add sequence number to 'xm info'

[Hollis Blanchard]

On Thursday 29 September 2005 11:05, Dan Smith wrote:
> HB> +If you want to compare two changesets, you already have the full
> HB> +date right in front of you!
>
> That's true.
>
> HB> The revision number is a convenience for *local* operations, for
> HB> example 'hg export 7033:7035'. It obviously should never be
> HB> compared across different repositories "and just hope things work
> HB> out ok."
>
> I completely agree and understand.  Telling someone to try to resolve
> their problem by checking out changeset 7033 would be a bad idea.
> However, if we're talking about loosely grouping and sorting a month's
> worth of test reports to make a determination about failure trends, I
> think it's a valid way to do it.  It's quick and it doesn't require
> any parsing of the date string.

Look at the way you phrased that: you aren't saying "a hundred revisions"; 
you're saying "a month". Maybe you could describe this classification process 
a little better. Are you looking to make statements like "dom0 booting was 
broken every week"?

And let's be honest: I'm not a big math fan, but the arithmetic on time zone 
conversions is not very difficult. :) 

> Also, when I'm comparing two of my test machines to see which is
> running a newer pull, I have to parse the date string with my eyes and
> do timezone conversions to figure out the order.  Since my (and most,
> I imagine) test machines are always running clones of the main repo,
> the sequence numbers would always be valid.

Sure, although if someone forgets what tree they're currently working in 
(happens to me anyways :), or doesn't have a pristine tree handy, or 
whatever...

> Independent of how people choose to use the information, is there a
> strong argument for not even showing it?

Because if you show it then people might be tempted to use the information. :) 
Revision numbers are local numbers, and should only be used locally.

I don't think "in this one case it will usually be ok" is a good argument, 
especially since "will always work" methods are readily available.

-- 
Hollis Blanchard
IBM Linux Technology Center