Re: Picking up the ball from Niclas (ugh!) on Velocity
On 2004-11-30 11:19:33, Eric Pugh wrote: > 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? This reminds me of a joke. A bloke with rather unusual sexual abilities is invited to give a public demonstration. A large crowd gathers in an arena while the bloke does it with 1, then 2, then 3 consenting adults of the opposite sex. The crowd begins to chant 10, 11, .., 95. At the 96th the bloke gets tired. He makes a last ditch effort, 97 ... 98. The crowd falls silent, and he makes it to 99. The 100th is too much for our bloke, who gives up. The crowd erupts yelling "Homosexual, Homesexual." If at the slightest sign of breakage you are going to blame people for being unfriendly or obtuse, Gump will not succeed in bringing people closer together. -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On 2004-11-30 18:10:34, Stefano Mazzocchi wrote > We tried, he's not listening, so we route around him. You, as a group, are the ones who are not listening. I've been playing this game for several years. Small breakages are part of the development cycle. You can either be pragmatic about the breakage or blow it out of proportion. As discussed on the members list, Gump will serve its social purpose if it is used wisely. If gump becomes dogma, then it will just upset the people you are trying to get closer to. Please take this as friendly advice, -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
Niclas Hedhman wrote: 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) Correct. We don't change people, we try to route around them, but we try first :-) Log4j has been, historically, a very collaborative project, but they (or just Ceki?) seemed to have turned sour. Can't tell why. I don't think he realizes that the reason why people used log4j was exactly this collaborative attitude and, without that, it will be a lot harder to market it. We tried, he's not listening, so we route around him. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On Nov 30, 2004, at 8:18 AM, Niclas Hedhman wrote: On Tuesday 30 November 2004 20:18, Geir Magnusson Jr wrote: On Nov 30, 2004, at 6:19 AM, Eric Pugh wrote: 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'm not asking for forever. Just one version... even a short lived one... My take away lesson is really more of a reaffirmation - don't depend on outside things if you can help it... Log4J has otherwise been very generous with having deprecated code around, but when I asked explicitly if this was a chagne for 1.3 and whether that means that everyone who uses RFA have to change the config files, I got from Ceki the answer; "Yes" to those two questions. Very strange change of attitude, and I don't know why this is happening. Yes, historically, log4j has bent over backwards to make things easy for users. geir Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On Tuesday 30 November 2004 20:18, Geir Magnusson Jr wrote: > On Nov 30, 2004, at 6:19 AM, Eric Pugh wrote: > > 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'm not asking for forever. Just one version... even a short lived > one... > > My take away lesson is really more of a reaffirmation - don't depend on > outside things if you can help it... Log4J has otherwise been very generous with having deprecated code around, but when I asked explicitly if this was a chagne for 1.3 and whether that means that everyone who uses RFA have to change the config files, I got from Ceki the answer; "Yes" to those two questions. Very strange change of attitude, and I don't know why this is happening. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On Nov 30, 2004, at 6:19 AM, Eric Pugh wrote: 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'm not asking for forever. Just one version... even a short lived one... My take away lesson is really more of a reaffirmation - don't depend on outside things if you can help it... -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Picking up the ball from Niclas (ugh!) on Velocity
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]
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]
RE: Picking up the ball from Niclas (ugh!) on Velocity
> -Original Message- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Gump is about establishing communication channels between development > communities. ROTFLOL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
Eric Pugh wrote: So, I thought I would just submit a patch to Velocity to fix the velocity/log4j problem and everything would be fine. Wrong.. The issue is the non backwards compatible API change to log4j. And, I saw Niclas email about it as well. So, I dug some more and according to this email: http:[EMAIL PROTECTED]/2004-11/msg00271.html there is a binary version. So I thought "hey, use that".. Only to discover that Gump can check out a tagged branch of code! And that there is a project called logging-log4j-12.xml already building that most dependees of log4j use. So, I made the change, and that should fix Velocity... Of course, it basically is like dynamically building a package.. Fulcrum Configuration relies on the older version of commons-configuration. I am going to apply the same trick there. I have spoken to Geir Magnuson, who was not aware that velocity was being a problem and I indicated the problem and he said he would solve it in a few minutes. People, Gump is *NOT* about 100% success. Gump is about establishing communication channels between development communities. If you are interested in the first and not in the second, run a cron job every night on your build files and send your list an email if that build goes wrong. it's a two seconds job and I'll be happy to give access to brutus if you need that. 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, then stick around for a few more years, because that's how much it will take before gump can be considered a success. The recent 'velocity stall' indicates that our way to signal problems is too noisy to convey information and Eric identified a few issues that I also have. The rule should be to start fixing gump and fix the communication channels rather than fixing the metadata to route around the problems. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
