Daniel F. Savarese wrote:
>
> In general, I recommend doing fresh checkouts for build verification.
> It's the only way to guarantee you know what you've got. I also heavily
> favor relatively frequent fresh checkouts during regular development,
> but nobody I work with ever buys into it until they get burned. Regardless
> of the revision control system, keeping a module checked out for extended
> periods of time will eventually cause problems (in my experience). Of
> course, this isn't exactly compatible with large code bases and low
> bandwidth connections.
My concern isn't bandwidth, but the loss of useful information. Knowing
that subproject x built yesterday and only three files changed today (or
better yet - no files changed, as was recently the case with xml-fop), is
*very* useful information.
A minor advantage of cvs update is that it is fault tolerant - if the
update fails, I simply run with yesterday's data again. It has been known
to happen.
One thing worth mentioning - these directories are maintained exclusively
by the cvs client. The gump process is to do an update then copy the
directory to another location and build it there. No artifacts from
previous builds are present.
>I don't know what to do about people ignorning naglist messages about
>broken builds or similar situations where they are cognizant of Gump.
>However, I don't think there's a high a level of awareness about Gump,
>so people don't stop to think that changes they're making will affect it.
>It was not particularly easy for me to get information about it and learn
>that there was a naglist, etc. How many people are even aware that they
>can check http://jakarta.apache.org/builds/gump/latest/?
My bad. I'll start work on a set of web pages which I will link off the
front Jakarta web page.
>My personal preference would be to have the failed build summary emailed
>to general@jakarta every day. I think that encourages everyone to develop
>a more global view of Jakarta projects. Gump has a community building
>potential that we're not taking advantage of. The only reason I know
>any other Jakarta projects are using jakarta-oro is because of the Gump
>dependency information you maintain. Now I know what projects to consult
>or at least warn before introducing a major change to jakarta-oro.
I'll look into producing a summary of failures to be sent to general. My
feeling is that the summary should only include jakarta projects. My
experience is that if you send people too much irrelevant information and
they start filtering it out.
I may also look into producing counts of days since a successful build .
>I know there will be objections to daily build emails, so maybe we
>can start with a monthly Gump FAQ mailing that explains what Gump
>is about and also a "hey, it would help out a lot if you let Sam know
>when you do something that Gump should know about" request. I believe
>it's best to keep Gump and build standardization an opt-in thing,
>but I don't see any reason why there can't be a little bit of polite
>and invitational nudging.
So far I seem to be successful in finding a balance between opt-in and
opt-out. If the data is useful, then I don't think there will be a
problem.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
