Fogbugz feedback - "Image Version"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Fogbugz feedback - "Image Version"

Ben Coman
A niggle I've had for a while is that the "Image Version" field seems to me to be useless.  

It defaults to a particular major version. 
(that even though only a small thing, is one more thing to maintain)

It tends to be superseded by the Milestone field.

The limited selection of major version is too broad to add any
useful info beyond Milestone to narrow down action.

So I wonder Image Version if it might be replaced by a freeform field
"Image Version" to enter the value from System > About.

-----
As an extension, given the flux of the VMs with the move to 64 bit, 
and ongoing support for both, it might also be good to have a "VM Version" field.

Now actually I often find it awkward to report VM version.
The text under System > System Reporter > VM General
is quite bulky and its not clear what is the really  useful parts for identification.
So I usually end up pasting the whole thing, but this is too much for
an issue tracker field.  Also, there is no indication here of itimer versus threaded heartbeats which is sometimes pertinent. 
Could suitable minimal VM version info be added to   System > About  
so the info required for the issue tracker is all in one simple place? 

-----
Finally, do we want these version fields to:
* remain static for the version initially reported on, or 
* be refreshed as confirmed in a later version, or
* have separate fields "Confirmed in {Image/VM} Version" to track tests.

cheers -ben 

cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz feedback - "Image Version"

Marcus Denker-4
> On 17 Mar 2017, at 04:32, Ben Coman <[hidden email]> wrote:
>
> A niggle I've had for a while is that the "Image Version" field seems to me to be useless.  
>
> It defaults to a particular major version.
> (that even though only a small thing, is one more thing to maintain)
>
> It tends to be superseded by the Milestone field.
>

Yes, and we ask to tell information about version used, platform etc in the issue description.

These things tend to change, too.

As a first step I think we should remove the Image Version field...

> The limited selection of major version is too broad to add any
> useful info beyond Milestone to narrow down action.
>
> So I wonder Image Version if it might be replaced by a freeform field
> "Image Version" to enter the value from System > About.
>
> -----
> As an extension, given the flux of the VMs with the move to 64 bit,
> and ongoing support for both, it might also be good to have a "VM Version" field.
>
> Now actually I often find it awkward to report VM version.
> The text under System > System Reporter > VM General
> is quite bulky and its not clear what is the really  useful parts for identification.
> So I usually end up pasting the whole thing, but this is too much for
> an issue tracker field.  Also, there is no indication here of itimer versus threaded heartbeats which is sometimes pertinent.
> Could suitable minimal VM version info be added to   System > About  
> so the info required for the issue tracker is all in one simple place?
>
> -----
> Finally, do we want these version fields to:
> * remain static for the version initially reported on, or
> * be refreshed as confirmed in a later version, or
> * have separate fields "Confirmed in {Image/VM} Version" to track tests.





Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz feedback - "Image Version"

Eliot Miranda-2
In reply to this post by Ben Coman
Hi Ben,

> On Mar 16, 2017, at 8:32 PM, Ben Coman <[hidden email]> wrote:
>
> A niggle I've had for a while is that the "Image Version" field seems to me to be useless.  
>
> It defaults to a particular major version.
> (that even though only a small thing, is one more thing to maintain)
>
> It tends to be superseded by the Milestone field.
>
> The limited selection of major version is too broad to add any
> useful info beyond Milestone to narrow down action.
>
> So I wonder Image Version if it might be replaced by a freeform field
> "Image Version" to enter the value from System > About.
>
> -----
> As an extension, given the flux of the VMs with the move to 64 bit,
> and ongoing support for both, it might also be good to have a "VM Version" field.
>
> Now actually I often find it awkward to report VM version.
> The text under System > System Reporter > VM General
> is quite bulky and its not clear what is the really  useful parts for identification.
> So I usually end up pasting the whole thing, but this is too much for
> an issue tracker field.  Also, there is no indication here of itimer versus threaded heartbeats which is sometimes pertinent.
> Could suitable minimal VM version info be added to   System > About  
> so the info required for the issue tracker is all in one simple place?

Perhaps we should start by enumerating use cares.  I originally wrote that bulky version info so that vm maintainers could identify the exact version of a VM.  The use case here is to locate or obtain the build date, c compiler and exact C and VMMaker source for the vm in order to locate the exact vm, attach a debugger, recompile a matching debug vm, etc.  At the time the version info was

a) the commit to the subversion Cog repository of the vm sources

b)  the commit to the subversion squeakvm repository of the vm support files shared between Cog and squeakvm

c) the VMMaker version of the StackInterpreter or CoInterpreter in the vm (including the "*" dirty mark if so)

d) the VMMaker version of the Cogit in the vm (including the "*" dirty mark if so)

With opensmalltalk-vm we can collapse a) and b), or rather, b) is no longer separate and hence obsolete, but the triad a), c) & d) are still most relevant to me.  Condensing these to a summary means having to index (e.g. lookup the VMMaker info in opensmalltalk-vm by checking out a particular commit) and that's time consuming.

So for me, while the info is poorly formatted and hard to read it is informative and saves me time.  I'm happy to see it paired down by dropping b), and doing whatever we can to make it more readable but I'd still like to see people cite it in full when reporting a potential vm problem or reporting their vm version.

What other use cases are there for this version info?  (and that's not a rhetorical question).

>
> -----
> Finally, do we want these version fields to:
> * remain static for the version initially reported on, or
> * be refreshed as confirmed in a later version, or
> * have separate fields "Confirmed in {Image/VM} Version" to track tests.
>
> cheers -ben
>
> cheers -ben
>

Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz feedback - "Image Version"

Sven Van Caekenberghe-2
I understand why it is useful to you, but it is a PIA for all the rest of us.

Consider:

$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

$ python --version
Python 2.7.10

$ ruby --version
ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]

At the image level Pharo has:

$ pharo Pharo.image printVersion
[version] 4.0 #40620

Clean, simple, precise.

And then when the rest of the world wants to communicate about the VM version they are using, you get:

$ ../bin/pharo --version
3.9-7 #1 Thu Apr  2 00:51:45 CEST 2015 gcc 4.6.3 [Production ITHB VM]
NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  2 2015
NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  2 2015
https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <[hidden email]> Jenkins build #14904
Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux
plugin path: /home/audio359/pharo/bin/pharo-vm/ [default: /home/audio359/pharo/bin/pharo-vm/]

This is way too technical.

On the other hand, I understand that this is also a vetting problem: who builds the VM, validates it, assigns it version/build numbers.

BTW, is there no open source convention of using xx-config to return all this detailed (build) info ?

> On 17 Mar 2017, at 11:36, Eliot Miranda <[hidden email]> wrote:
>
> Hi Ben,
>
>> On Mar 16, 2017, at 8:32 PM, Ben Coman <[hidden email]> wrote:
>>
>> A niggle I've had for a while is that the "Image Version" field seems to me to be useless.  
>>
>> It defaults to a particular major version.
>> (that even though only a small thing, is one more thing to maintain)
>>
>> It tends to be superseded by the Milestone field.
>>
>> The limited selection of major version is too broad to add any
>> useful info beyond Milestone to narrow down action.
>>
>> So I wonder Image Version if it might be replaced by a freeform field
>> "Image Version" to enter the value from System > About.
>>
>> -----
>> As an extension, given the flux of the VMs with the move to 64 bit,
>> and ongoing support for both, it might also be good to have a "VM Version" field.
>>
>> Now actually I often find it awkward to report VM version.
>> The text under System > System Reporter > VM General
>> is quite bulky and its not clear what is the really  useful parts for identification.
>> So I usually end up pasting the whole thing, but this is too much for
>> an issue tracker field.  Also, there is no indication here of itimer versus threaded heartbeats which is sometimes pertinent.
>> Could suitable minimal VM version info be added to   System > About  
>> so the info required for the issue tracker is all in one simple place?
>
> Perhaps we should start by enumerating use cares.  I originally wrote that bulky version info so that vm maintainers could identify the exact version of a VM.  The use case here is to locate or obtain the build date, c compiler and exact C and VMMaker source for the vm in order to locate the exact vm, attach a debugger, recompile a matching debug vm, etc.  At the time the version info was
>
> a) the commit to the subversion Cog repository of the vm sources
>
> b)  the commit to the subversion squeakvm repository of the vm support files shared between Cog and squeakvm
>
> c) the VMMaker version of the StackInterpreter or CoInterpreter in the vm (including the "*" dirty mark if so)
>
> d) the VMMaker version of the Cogit in the vm (including the "*" dirty mark if so)
>
> With opensmalltalk-vm we can collapse a) and b), or rather, b) is no longer separate and hence obsolete, but the triad a), c) & d) are still most relevant to me.  Condensing these to a summary means having to index (e.g. lookup the VMMaker info in opensmalltalk-vm by checking out a particular commit) and that's time consuming.
>
> So for me, while the info is poorly formatted and hard to read it is informative and saves me time.  I'm happy to see it paired down by dropping b), and doing whatever we can to make it more readable but I'd still like to see people cite it in full when reporting a potential vm problem or reporting their vm version.
>
> What other use cases are there for this version info?  (and that's not a rhetorical question).
>
>>
>> -----
>> Finally, do we want these version fields to:
>> * remain static for the version initially reported on, or
>> * be refreshed as confirmed in a later version, or
>> * have separate fields "Confirmed in {Image/VM} Version" to track tests.
>>
>> cheers -ben
>>
>> cheers -ben


Reply | Threaded
Open this post in threaded view
|

Re: Fogbugz feedback - "Image Version"

Ben Coman


On Fri, Mar 17, 2017 at 7:47 PM, Sven Van Caekenberghe <[hidden email]> wrote:
I understand why it is useful to you, but it is a PIA for all the rest of us.

Consider:

$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

$ python --version
Python 2.7.10

$ ruby --version
ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]

At the image level Pharo has:

$ pharo Pharo.image printVersion
[version] 4.0 #40620

Clean, simple, precise.

And then when the rest of the world wants to communicate about the VM version they are using, you get:

$ ../bin/pharo --version
3.9-7 #1 Thu Apr  2 00:51:45 CEST 2015 gcc 4.6.3 [Production ITHB VM]
NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  2 2015
NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  2 2015
https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <[hidden email]> Jenkins build #14904
Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux
plugin path: /home/audio359/pharo/bin/pharo-vm/ [default: /home/audio359/pharo/bin/pharo-vm/]

This is way too technical.

This just needs to be --versionVerbose or --versionAll.

cheers -ben 
 
On the other hand, I understand that this is also a vetting problem: who builds the VM, validates it, assigns it version/build numbers.

BTW, is there no open source convention of using xx-config to return all this detailed (build) info ?

> On 17 Mar 2017, at 11:36, Eliot Miranda <[hidden email]> wrote:
>
> Hi Ben,
>
>> On Mar 16, 2017, at 8:32 PM, Ben Coman <[hidden email]> wrote:
>>
>> A niggle I've had for a while is that the "Image Version" field seems to me to be useless.
>>
>> It defaults to a particular major version.
>> (that even though only a small thing, is one more thing to maintain)
>>
>> It tends to be superseded by the Milestone field.
>>
>> The limited selection of major version is too broad to add any
>> useful info beyond Milestone to narrow down action.
>>
>> So I wonder Image Version if it might be replaced by a freeform field
>> "Image Version" to enter the value from System > About.
>>
>> -----
>> As an extension, given the flux of the VMs with the move to 64 bit,
>> and ongoing support for both, it might also be good to have a "VM Version" field.
>>
>> Now actually I often find it awkward to report VM version.
>> The text under System > System Reporter > VM General
>> is quite bulky and its not clear what is the really  useful parts for identification.
>> So I usually end up pasting the whole thing, but this is too much for
>> an issue tracker field.  Also, there is no indication here of itimer versus threaded heartbeats which is sometimes pertinent.
>> Could suitable minimal VM version info be added to   System > About
>> so the info required for the issue tracker is all in one simple place?
>
> Perhaps we should start by enumerating use cares.  I originally wrote that bulky version info so that vm maintainers could identify the exact version of a VM.  The use case here is to locate or obtain the build date, c compiler and exact C and VMMaker source for the vm in order to locate the exact vm, attach a debugger, recompile a matching debug vm, etc.  At the time the version info was
>
> a) the commit to the subversion Cog repository of the vm sources
>
> b)  the commit to the subversion squeakvm repository of the vm support files shared between Cog and squeakvm
>
> c) the VMMaker version of the StackInterpreter or CoInterpreter in the vm (including the "*" dirty mark if so)
>
> d) the VMMaker version of the Cogit in the vm (including the "*" dirty mark if so)
>
> With opensmalltalk-vm we can collapse a) and b), or rather, b) is no longer separate and hence obsolete, but the triad a), c) & d) are still most relevant to me.  Condensing these to a summary means having to index (e.g. lookup the VMMaker info in opensmalltalk-vm by checking out a particular commit) and that's time consuming.
>
> So for me, while the info is poorly formatted and hard to read it is informative and saves me time.  I'm happy to see it paired down by dropping b), and doing whatever we can to make it more readable but I'd still like to see people cite it in full when reporting a potential vm problem or reporting their vm version.
>
> What other use cases are there for this version info?  (and that's not a rhetorical question).
>
>>
>> -----
>> Finally, do we want these version fields to:
>> * remain static for the version initially reported on, or
>> * be refreshed as confirmed in a later version, or
>> * have separate fields "Confirmed in {Image/VM} Version" to track tests.
>>
>> cheers -ben
>>
>> cheers -ben