[prev in list] [next in list] [prev in thread] [next in thread] 

List:       alexandria-dev
Subject:    RE: Blame ML
From:       Jeff Martin <jeff.martin () synamic ! co ! uk>
Date:       2000-09-28 13:37:46
[Download RAW message or body]

I knew someone would come up with this ;o). I kinda like the idea of being
slightly blamed every so often. It's much better than being blamed once in a
blue moon when something really major has developed.

It all kinda appeals to my sense of humour. I was thinking about using XSL
to transform blame documents into Speech Synthesis Markup Language so it can
tell everyone who's fault it is.

More seriously, if anyone can think of a better name for these elements let
me know and I'll consider them.

-----Original Message-----
From: Shane_Curcuru@lotus.com [mailto:Shane_Curcuru@lotus.com]
Sent: 28 September 2000 13:39
To: alexandria-dev@java.apache.org
Subject: Re: Blame ML


Jeff - sounds like a good idea overall!  I really like some of the stuff
going on in Alexandria and using Ant to tie simple software processes
together.

I'd like to consider *not* calling it 'Blame ML' and having 'suspect'
attributes though.  Developers can get touchy about being 'blamed' for
breaking the build, and this might get a bit more of a negative connotation
than we really need.  Plus, sometimes it's either not really that
'suspects' fault (i.e. conflicting checkins in different files) or
committers on some project are re-working a large area of the project that
particular day.  Especially if/when you use Alexandria to build multiple
Apache projects - including some other projects where not all the
committers may be aware of Alexandria and your plans.

---- You Jeff Martin <jeff.martin@synamic.co.uk> wrote: ----
> I've started a bit of work on getting automatic builds running from
> Alexandria.
...
> As far as the blame side goes. I think the best thing is to create a
custom
> build listener for ant which listens for the build events and will and
the
> info to an xml blame file.

Oh, and definitely store info in XML and style it in XSL - and remember,
often half the battle when trying to filter or style data for output with
XSL is in structuring your XML data.  I.e., think about what kinds of
external reports you'll want later (an auto-generated web page with a big
chart of today's problems; a utility to auto-email specific problems to the
listed person's apache email address, etc.) and format your XML output
based partly on that.

----    ----
- Shane        Automation, Test & Build guy
mailto:shane_curcuru@lotus.com  AIM:xsltest
  http://alphaworks.ibm.com/tech/LotusXSL
  http://xml.apache.org/xalan


---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@java.apache.org
For additional commands, e-mail: alexandria-dev-help@java.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]