[Vm-dev] Questions, communication and process
stephane.ducasse at gmail.com
Fri Apr 9 19:41:51 UTC 2010
excellent I forwarded that to the pharo mailing-list
On Apr 9, 2010, at 2:52 PM, David T. Lewis wrote:
> On Fri, Apr 09, 2010 at 11:23:18AM +0200, stephane ducasse wrote:
>> Hi vm guys,
>> I would like to know the process to report problems, issues, enh to the vm because people asked me
>> and I have no idea how this is done. I read the web site but I could not find a bugtracker.
> Hi Stef,
> In addition to Ian's explanations, I'll add couple of points.
>> Several questions:
>> - How do people report problems? Just sending an email in the mailing-list is enough?
> The bugtracker is Mantis at bugs.squeak.org. Use category "VM" when
> reporting or searching for problems. For any problems or enhancement
> requests that may time time to resolve, it is very helpful to use
> the bugtracker because it provides a process for ensuring that issues
> are addressed or at least not forgotten, and also a reference for
> people who run into an issue that someone else has addressed.
> I try to catch issues that I see on the Pharo and squeak-dev lists
> and enter them on Mantis if they will need follow up, but I'm sure
> that I miss things from time to time.
> Follow Ian's instructions for reporting problems to vm-dev and the
> platform developer. That is the way that problems get noticed,
> discussed, and addressed. But to ensure follow-up, please also
> use the bugtracker.
>> - How a fix in one OS is propagated to the others?
>> - How the user can know that?
> For issues that affect the VM overall, the change history of the
> VMMaker package on squeaksource is helpful. You can use Monticello
> of course, but I like to point a web browser at www.squeaksource.com,
> project VMMaker, and browse through the entries under the "News" tab.
> A remaining problem is that that the VM user cannot always tell if
> their VM actually contains a particular fix or feature. To some extent
> you can figure it out from the name of the VM file, but we need a better
> run time check. We (or I) will probably add a way to check this through
> a primitive, but for now it remains confusing.
More information about the Vm-dev