Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
From: Niclas Hedhman <niclas@hedhman.org>
Organization: Private
To: general@gump.apache.org
Subject: [RT] Selling Gump...
Date: Tue, 19 Oct 2004 06:34:36 +0800
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200410190634.36399.niclas@hedhman.org>


I think we need a major re-think about what Gump is and how it is perceived 
among our peers.

Gump -  The Apache Continous Integration Service.

Keyword; "Service".

We need to get rid of the "nags" in their current form. They are probably too 
intrusive and irritating. Instead of providing value to the projects, it 
creates at best an 'ignorance' of those messages. I think any project that 
are somewhat downstream, is no longer bothering about the Gump messages.

I am not entirely sure what should be done, since the best solution I can 
think of is probably not applicable, and that is that whenever a commit is 
made, the project and all dependees are built, and if it fails, the 
'notification' goes to the committer.
We don't have enough CPU resources for such a brute approach.

But I think we need to somehow tie the 'commits' into the build loop, so what 
when a regression occurs, a list of commits that may have affected that build 
can be reviewed easily.

And secondly, let the Gump folks redirect the notifications manually, to where 
we believe them to belong.

WDYT?

Cheers
Niclas
-- 
   +------//-------------------+
  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 
+------//-------------------+


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org