Hi Ben,

    please include the squeak list in this discussion  It's clearly
relevant to the whole community.

On Fri, Feb 8, 2013 at 4:12 PM, Benjamin <
benjamin.vanryseghem.pharo at gmail.com> wrote:

>
> On Feb 9, 2013, at 1:06 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Fri, Feb 8, 2013 at 3:10 PM, Marcus Denker <marcus.denker at inria.fr>wrote:
>
>>
>> On Feb 9, 2013, at 12:01 AM, Frank Shearar <frank.shearar at gmail.com>
>> wrote:
>>
>> > On 8 February 2013 22:51, Marcus Denker <marcus.denker at inria.fr> wrote:
>> >>
>> >> On Feb 8, 2013, at 11:49 PM, Frank Shearar <frank.shearar at gmail.com>
>> wrote:
>> >>
>> >>> On 8 February 2013 22:41, Marcus Denker <marcus.denker at inria.fr>
>> wrote:
>> >>>>
>> >>>> On Feb 8, 2013, at 11:34 PM, Camillo Bruni <camillobruni at gmail.com>
>> 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
>

So two questions.  a) What are the candidates?  b) how much effort do you
think it would be, compared to the interface you've already built,
implementing a bug tracker with a scriptable interface?  It is essentially
an evolveable DB schema plus some triggers to send emails, right?


> Ben
>
>
>
>
>>
>>         Marcus
>>
>
>
>
> --
> best,
> Eliot
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130208/7faebeb3/attachment.htm