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