Re: [Pharo-project] New Issue Tracker

On Feb 9, 2013, at 1:06 AM, Eliot Miranda <[hidden email]> wrote:

On Fri, Feb 8, 2013 at 3:10 PM, Marcus Denker <[hidden email]> wrote:

On Feb 9, 2013, at 12:01 AM, Frank Shearar <[hidden email]> wrote:

> On 8 February 2013 22:51, Marcus Denker <[hidden email]> wrote:
>>
>> On Feb 8, 2013, at 11:49 PM, Frank Shearar <[hidden email]> wrote:
>>
>>> On 8 February 2013 22:41, Marcus Denker <[hidden email]> wrote:
>>>>
>>>> On Feb 8, 2013, at 11:34 PM, Camillo Bruni <[hidden email]> wrote:
>>>>
>>>>>>>
>>>>>>
>>>>>> That's not a valid comparison.  In Squeak trunk bugs are getting fixed at a
>>>>>> much higher rate
>>>>
>>>> Are you sure? The list that Craig showed at Fosdem was rather short.
>>>
>>> Well, obviously Squeak is a rather smaller community, so that's hardly
>>> surprising.
>>>
>>> Squeakers _do_ need to use bugs.squeak.org, but as I'm sure you know
>>> from getting Pharo going, this is partly a matter of education.
>>>
>>
>> It is a matter of someone doing it.
>
> ... and convincing people to do it is called education. Note my use of
> the word "partly". Anyway, I'm not sure why you're getting stuck into
> this. You sound annoyed.

I will always be annoyed about that topic… ;-)

Quite right too.  The issue for me is that the bug trackers are not well-enough integrated into my Squeak work flow.  Montivcello is beautifully integrated into the work flow and hence a joy to use.  I'm not proposing reinventing the wheel and writing a Squeak/Pharo bug tracker (although we did that at ParcPlace/ObjectShare/Cincom and the results were excellent).  But at the same time I don't want to go to an external web page to read bugs (althoguh I'm willing to) and I *definitely* don't want to go there to update fixes.  I want to update fixes from my Monticello check-in and/or TestRunner.

I wonder whether it is feasible to provide a skin to an existing, popular bug tracker so that at least one can have the updating/closing side of the work-flow brought much closer to Monticello check-in/TestRunner?

Wouldn't the ideal work-flow be built around an interface between TestRunner and a bug tracker?  If we built such an interface wouldn't there be much greater use?  Imagine being able to have one-click (plus filling in a description in a submit dialogue) bug creation from TestRunner?  And e.g. using pragmas or some-such, add the state and history, or simply the pointer to the bug tracker page, embedded in the test case?  Then one could read, in-image, the state of the bug long after it was fixed, in the context of the test that demonstrated the bug and its fix.

That's exactly why Camillo and I spent so much time implementing a Google Issue Tracker API in Smalltalk :)

And why we are looking for an alternative solution providing a scriptable API

Ben

 

        Marcus

--
best,

Eliot