Re: Fulcrum building again (was: VOTE)

["Daniel F. Savarese" <df...@savarese.org>]

In message <OF...@raleigh.ibm.com>, "Sam Ruby
" writes:
>Jon Stevens wrote:
>Yup.  It looked like a clean checkout solved the problem.  I'm still
>inclined to stick with update for the normal case.

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.

>Now that I know that I can't completely trust cvs, the next time should be
>quicker.  But that's not the point.
>
>Anybody have any suggestions for improvements of the social aspects of this
>problem?

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 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 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.

daniel



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