[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eshell-defgroup. Do we really need this?

From: Ted Zlatanov
Subject: Re: eshell-defgroup. Do we really need this?
Date: Mon, 04 Aug 2008 11:34:49 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)

On Sat, 02 Aug 2008 13:18:15 +0900 "Stephen J. Turnbull" <address@hidden> 

SJT> Ted Zlatanov writes:
>> On Fri, 01 Aug 2008 19:08:04 +0200 Romain Francoise <address@hidden> wrote: 

RF> My experience with running this buildbot (and others) suggests that
RF> there is little value in doing this; buildbot does a clean build
RF> every time so if it fails then we can be fairly sure that CVS is
RF> broken.
>> You think so even considering the large amount of people that would get
>> this report?  I'd rather be cautious and have at least one confirmation
>> of the failure before reporting it.  But, of course, it's your
>> choice--as long as we report something.

SJT> Romain's right, you don't need confirmation.  If a clean build breaks,
SJT> it's broke.  What to do about it is another question.

Builds can break for many reasons, some local (e.g. disk full).  Why
bother many people with a false report?  It would condition them to
ignore truly broken builds.  That's my concern.

SJT> XEmacs has a separate list for build reports, whether user-contributed
SJT> or automatic.  From Richard's comments about the BTS, I'd put money on
SJT> him wanting a separate list for this, too.  (That's 'cause I really
SJT> like the odds, not because I speak for Richard.)  Works for us.  (We
SJT> don't use buildbot, yet.)

SJT> Python core just assumes that people (and in particular the release
SJT> engineers) will be watching the buildbot's waterfall URL.  Works for
SJT> them.

SJT> Python also has a system of "community" (ie, apps written in Python)
SJT> buildbots with the intent of notifying somebody that the dev lines of
SJT> Python are breaking stable builds.  Current status is "failing
SJT> miserably", as nobody pays attention to them.  That is For reasons
SJT> that I don't think apply to Emacs, but for the sake of completeness I
SJT> include the case here.

Thanks for explaining.  I think the case for Emacs is simpler, but I am
certainly not the one to make any decisions about it.  I just want to
provide the service because I want to do something about broken builds.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]