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