I think what he means is that we can't expect people to make changes just to make Gump happy. But, we can *attempt* to influence them to help. And I think that is where we are going wrong. For instance, Fulcrum components didn't build very well until I got involved (and got lots of help!).. You need a committer from the project being gumped to keep things running well. As far as I know, there are no log4j committers actively involved in keeping gump working. Hence, they made a backwards incompatible change, and the fact that gump keeled over doesn't bother then.
Now, partly that may be a communication thing.. If Log4j fails, they get emailed. If log4j breaks every body else, they don't... Without active involvement by a group, the prospect of keeping things working becomes a thankless task (witness Niclas's frustration). I thought "hey, I'll try and help" and ran into, in an hour, the same frustration Niclas sees.. I am not a committer (or even involved beyond the occasional email) with Log4j or Velocity, so who do I got to prod for action? Geir's email highlights a very clear issue with the whole deprecation/version cycle. He can't switch to log4j until it releases. They don't want to keep deprecated code around for forever. I'll argue that neither party is at fault. It's just an icky sore spot that will be worked out at somepoint, and gump is just bringing up the incompatiblity sooner. I'd like Gump to now just say "Yes, log4j HEAD fails on Velocity, lets step back to the last successful build with Velocity and use that", or, we work around it by building in Gump the older version (logging_log4j_12) and use that. I don't specifically think it is a tooling issue.. This stuff is hard, and while some rote stuff could be made simpler with better tooling, we are always going to have odd situations to deal with. So, I'll again argue about the benefit of packages/custom branches.. We need to build up mindshare the gump is this great build tool/continous integration tool. But we certainly can't wait a couple years, and I think that certain components that break frequently need to be packaged to provide some stability, as well as pruning some leaves that never build. Anything that hasn't built in the last 300 cycles for instance should be canned! At least, until we get some stability in gump... Eric > -----Original Message----- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 30, 2004 6:36 AM > To: Gump code and data > Subject: Re: Picking up the ball from Niclas (ugh!) on Velocity > > > On Tuesday 30 November 2004 07:45, Stefano Mazzocchi wrote: > > > Gump is about establishing communication channels between development > > communities. > > > On the other hand, if you are interested in creating a social > > engineering support tool and you are willing to get your hands dirty in > > python and prepare to have a huge ton of patience to convert a few > > hundreds people to a very difficult concept, > > > The rule should be to start fixing gump and fix the communication > > channels rather than fixing the metadata to route around the problems. > > Cool, but then you told me "Don't change people" & "we should > work around them > [projects not willing to co-operate]"... > > I would call that mixed signals... ;o) > > Cheers > Niclas > > P.S. Let me know when you figured out that Java is a better tool > after all :o) > so I can help more actively. > > > -- > +------//-------------------+ > / http://www.dpml.net / > / http://niclas.hedhman.org / > +------//-------------------+ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
