[Vm-dev] [Pharo-dev] Fogbugz feedback - "Image Version"

[Ben Coman]

On Fri, Mar 17, 2017 at 6:36 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Ben,
>
> > On Mar 16, 2017, at 8:32 PM, Ben Coman <btc at openinworld.com> 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).
>

Hi Eliot,
II'll think further on your response, but first a quick answer.
My intent was not to reduce the existing info at System > System Reporter.
I presumed the detail presented there was its best format "when required"
to dig further into particular VM problems.
But that detail doesn't need to attached to *every* issue.
Whereas the condensed VM-info I propose is for attaching to *every* issue.
This is to make it obvious when someone is running Pharo 6 on a Pharo 3 VM.
It also provides a quick proxy for which platform its run on without the
tedium of asking every time.
System>>About  is an intuitive place people look for version info, so its a
good place for the condensed-VM-info to quickly copy into the issue
tracker.

cheers -ben


>
> >
> > -----
> > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170317/347c019c/attachment.html>