Re: [vote] turning off nagging until we feel gump is solid enough for that
On Dec 2, 2004, at 7:10 AM, Ceki Gülcü wrote: At 12:41 PM 12/2/2004, Geir Magnusson Jr wrote: In this case, I'm the moron because I can't figure out what to do in velocity to deal w/ 1.3 (as well as log4j-dependent code that I have elsewhere), other than to make log4j support an option and force users to deal with it. Not my first choice. Geir, Ignore 1.3 for the time being. We will figure something out later in the 1.3 development cycle. How is that? Hey! Ceki's back! The guy I really admire! Where were you hidden? :D Yes, that's great. I'll see if I can find a cycle or two to help. geir geir -- 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] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
Stefan Bodewig wrote: On Thu, 2 Dec 2004, Eric Pugh <[EMAIL PROTECTED]> wrote: Is there a feeling that attempting to build with previous versions that passed isn't a good idea? Not at all. It is a very good idea that only needs to get coded. The "only" is the problem here. And I have the algorithm ready too :-) I just need to sit down and code this, but first I need to have Dynagump running because the historical information is critical for that algorithm to work and current gump's historical information sucks pretty bad. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
On Thu, 2 Dec 2004, Eric Pugh <[EMAIL PROTECTED]> wrote: > Is there a feeling that attempting to build with previous versions > that passed isn't a good idea? Not at all. It is a very good idea that only needs to get coded. The "only" is the problem here. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] turning off nagging until we feel gump is solid enough for that
I'm glad to see that Ceki is looking for the same thing I am looking for.. Notification of when my dependee's break due to my code change. I *think* that is MUCH more important then notification of when my dependency breaks. But, it all depends on the projects orientation. The needs of project with LOTS of dependees like Ant or Log4j are quite different from the needs of a project with very few dependee's but lots of dependencies like Scarab or Turbine. Out of curiosity, could these types of notifications be made as options? With some sort of sane defaults? Is there a feeling that attempting to build with previous versions that passed isn't a good idea? If project A depends on B, and then A fails due to incompatiblities with B, is it possible to try and build with the last version of B that was used when A actually built? Not sure how to express this in mathematical terms. This would allow for more things to build, but would require clear notification that project A can't build with the latest of B, but is okay with an older version. That is basically what projects are doing with the logging-log4j-12 branch, but in a manual fashion. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
At 12:41 PM 12/2/2004, Geir Magnusson Jr wrote: In this case, I'm the moron because I can't figure out what to do in velocity to deal w/ 1.3 (as well as log4j-dependent code that I have elsewhere), other than to make log4j support an option and force users to deal with it. Not my first choice. Geir, Ignore 1.3 for the time being. We will figure something out later in the 1.3 development cycle. How is that? geir -- 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: [vote] turning off nagging until we feel gump is solid enough for that
On Dec 1, 2004, at 10:12 AM, Ceki Gülcü wrote: At 03:44 PM 12/1/2004, Stefano Mazzocchi wrote: I think it's better if we start to nag ourselves first and see how we can increase the signal/noise ratio before we go back public. It's not only about gump's signal/noise ratio but the attitude adopted when things break. Allowing unaware developers to become aware that things broke (or may brake) offers tangible benefits. Once the dialog is triggered, it should go both ways. Depicting gump offenders as morons won't get us anywhere. In the past, the social algorithm for gump has been: 1) Gump checks for dependency issues. 2) If gump detects problems, social pressure is applied on the offender until the offenders yield. Otherwise, the offender is depicted as an insensitive moron. In this case, I'm the moron because I can't figure out what to do in velocity to deal w/ 1.3 (as well as log4j-dependent code that I have elsewhere), other than to make log4j support an option and force users to deal with it. Not my first choice. geir I suggest you review this social algorithm. -- Stefano. -- 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] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
Ceki Gülcü wrote: At 05:27 PM 12/1/2004, Stefano Mazzocchi wrote: If you have a better social algorithm that would stop you from feeling insulted, let us know what it is. It's not about me, log4j or velocity, but coming to the realization that 100% backward compatibility is not always possible. Absolutely agreed. I am a strong believer in dynamic equilibria and adaptation, not in stagnation as the way to obtain solidity. It seems that gump is based on the premise that an item can be removed in version n, if it has been deprecated on version k, where k < n. Although most reasonable, this policy cannot always be followed, for legitimate reasons. Yes, this is the fulcrum of the whole discussion and I'm actually glad that this surfaced because it did make me think a lot. Creating a social algorithm that allows the above will require a lot more work than I expected, but you are right: we cannot expect people to be good contract managers all the time [for whatever reason] (or even to understand what contract management is about). Don't understand me wrong, I very much appreciate Gump as a service. For example, log4j developers would like to be notified of changes in log4j CVS head that affect dependents. However, many dependents do not need to be aware of these changes, only log4j developers need to know about them. Before releasing the next version, we will publish a step-by-step migration document. Detecting that project V broke because of changes in project L, and then notifying only L, is a lot more complicated than what gump does currently. Surely that's asking too much out of Gump. Not really, Leo and I spent several days designing proving that the algorithm for this is computationally tractable. Our goal is not to insult people or to create trouble. Ditto here. Appreciated. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
At 05:27 PM 12/1/2004, Stefano Mazzocchi wrote: If you have a better social algorithm that would stop you from feeling insulted, let us know what it is. It's not about me, log4j or velocity, but coming to the realization that 100% backward compatibility is not always possible. It seems that gump is based on the premise that an item can be removed in version n, if it has been deprecated on version k, where k < n. Although most reasonable, this policy cannot always be followed, for legitimate reasons. Don't understand me wrong, I very much appreciate Gump as a service. For example, log4j developers would like to be notified of changes in log4j CVS head that affect dependents. However, many dependents do not need to be aware of these changes, only log4j developers need to know about them. Before releasing the next version, we will publish a step-by-step migration document. Detecting that project V broke because of changes in project L, and then notifying only L, is a lot more complicated than what gump does currently. Surely that's asking too much out of Gump. Our goal is not to insult people or to create trouble. Ditto here. -- Stefano. -- 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: [vote] turning off nagging until we feel gump is solid enough for that
Ceki Gülcü wrote: At 03:44 PM 12/1/2004, Stefano Mazzocchi wrote: I think it's better if we start to nag ourselves first and see how we can increase the signal/noise ratio before we go back public. It's not only about gump's signal/noise ratio but the attitude adopted when things break. Allowing unaware developers to become aware that things broke (or may brake) offers tangible benefits. Once the dialog is triggered, it should go both ways. Depicting gump offenders as morons won't get us anywhere. In the past, the social algorithm for gump has been: 1) Gump checks for dependency issues. 2) If gump detects problems, social pressure is applied on the offender until the offenders yield. Otherwise, the offender is depicted as an insensitive moron. I suggest you review this social algorithm. Gump spot a problem that was caused by log4j that impacted velocity. "cause" and "impact" are used without negative connotation, just an evidence of a fact. This problem lasted for 35 runs. This triggered concerns in the gump list as Niclas decided to quit for that, feeling that the system is simply too fragile. People's reaction was to intervene and Eric proposed to change the velocity dependency from log4j to log4j-12. On the other side, I decided that it might have been a trivial change so I contacted Geir and asked him to change. Note how, up to this point, you nor log4j were not involved at all. Geir rushed to fix the problem and found out that it was harder to fix than he expected, because log4j didn't deprecate the contract in a released version before breaking it. Again, this is a *FACT*, not a judgement. *He* asked you to make a smoother transition for that contract change, in order to allow a smoother transition for velocity users once log4j 1.3 is released. Your response was that you don't have the resources to do that. At this point, our reaction was to change the dependency between velocity and log4j so that we could move on. If you have a better social algorithm that would stop you from feeling insulted, let us know what it is. Our goal is not to insult people or to create trouble. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] turning off nagging until we feel gump is solid enough for that
You are right about the patch.. :-) Should scratch my own itches! Unfortunantly I know zip about python, but maybe it's time to learn. > -Original Message- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 01, 2004 3:44 PM > To: Gump code and data > Subject: Re: [vote] turning off nagging until we feel gump is solid > enough for that > > > Eric Pugh wrote: > > I think that it's more complex then just turning it on or off.. I'm in > > favor of turning it off for now if thats the only option. What > I prefer is > > that if a prereq doesn't build/builds finally, I don't get > nagged. That is > > what generates (typically) the flood of emails... I only care > if my project > > doesn't build/builds... > > Feel free to submit a patch. :-D > > No, seriously, gump is not really up to the task of keeping up with a > community of users that see it as a pain in the ass (myself included). > > I think it's better if we start to nag ourselves first and see how we > can increase the signal/noise ratio before we go back public. > > -- > Stefano. > > > - > 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: [vote] turning off nagging until we feel gump is solid enough for that
At 03:44 PM 12/1/2004, Stefano Mazzocchi wrote: I think it's better if we start to nag ourselves first and see how we can increase the signal/noise ratio before we go back public. It's not only about gump's signal/noise ratio but the attitude adopted when things break. Allowing unaware developers to become aware that things broke (or may brake) offers tangible benefits. Once the dialog is triggered, it should go both ways. Depicting gump offenders as morons won't get us anywhere. In the past, the social algorithm for gump has been: 1) Gump checks for dependency issues. 2) If gump detects problems, social pressure is applied on the offender until the offenders yield. Otherwise, the offender is depicted as an insensitive moron. I suggest you review this social algorithm. -- Stefano. -- 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: [vote] turning off nagging until we feel gump is solid enough for that
Eric Pugh wrote: I think that it's more complex then just turning it on or off.. I'm in favor of turning it off for now if thats the only option. What I prefer is that if a prereq doesn't build/builds finally, I don't get nagged. That is what generates (typically) the flood of emails... I only care if my project doesn't build/builds... Feel free to submit a patch. :-D No, seriously, gump is not really up to the task of keeping up with a community of users that see it as a pain in the ass (myself included). I think it's better if we start to nag ourselves first and see how we can increase the signal/noise ratio before we go back public. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
On Tue, 30 Nov 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > I think gump's nagging is currently making more noise than signal > and this is hurting our ability to come across as helpful instead of > annoying. Maybe. I agree with Eric that the "you no longer have a problem" mails are a particularly annoying. > I propose to turn off nagging until we fix this, which means we first need to agree what a fixed version would be 8-) I agree if we still send nags to [EMAIL PROTECTED] or [EMAIL PROTECTED] And we could remove the "success nags" completely, at least for me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
Stefano Mazzocchi wrote: I think gump's nagging is currently making more noise than signal and this is hurting our ability to come across as helpful instead of annoying. I propose to turn off nagging until we fix this, we are the only one making changes to the metadata anyway, so there is no much point in that. WDYT? let's try and redirect them all to [EMAIL PROTECTED] We probably do need to make some noise about this happening, since it'll probably take a while before our feelings change, and people might be expecting to be notified about stuff. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] turning off nagging until we feel gump is solid enough for that
I think that it's more complex then just turning it on or off.. I'm in favor of turning it off for now if thats the only option. What I prefer is that if a prereq doesn't build/builds finally, I don't get nagged. That is what generates (typically) the flood of emails... I only care if my project doesn't build/builds... Eric > -Original Message- > From: Scott Sanders [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 30, 2004 8:43 PM > To: Gump code and data > Subject: Re: [vote] turning off nagging until we feel gump is solid > enough for that > > > +1. Our probes are getting more done than nagging right now. > > On Nov 30, 2004, at 11:39 AM, Stefano Mazzocchi wrote: > > > I think gump's nagging is currently making more noise than signal and > > this is hurting our ability to come across as helpful instead of > > annoying. > > > > I propose to turn off nagging until we fix this, we are the only one > > making changes to the metadata anyway, so there is no much point in > > that. > > > > WDYT? > > > > -- > > Stefano. > > > > > > - > > 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
+1. Our probes are getting more done than nagging right now. On Nov 30, 2004, at 11:39 AM, Stefano Mazzocchi wrote: I think gump's nagging is currently making more noise than signal and this is hurting our ability to come across as helpful instead of annoying. I propose to turn off nagging until we fix this, we are the only one making changes to the metadata anyway, so there is no much point in that. WDYT? -- Stefano. - 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: [vote] turning off nagging until we feel gump is solid enough for that
On Tue, 30 Nov 2004 11:39:07 -0800, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > I think gump's nagging is currently making more noise than signal and > this is hurting our ability to come across as helpful instead of annoying. > > I propose to turn off nagging until we fix this, we are the only one > making changes to the metadata anyway, so there is no much point in that. > > WDYT? Would the nags then go to the Gump list instead? +1 if so. -0 otherwise... > -- > Stefano. > > - > 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: [vote] turning off nagging until we feel gump is solid enough for that
+1 from me. On Tue, 30 Nov 2004 11:39:07 -0800, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > I think gump's nagging is currently making more noise than signal and > this is hurting our ability to come across as helpful instead of annoying. > > I propose to turn off nagging until we fix this, we are the only one > making changes to the metadata anyway, so there is no much point in that. > > WDYT? > > -- > Stefano. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] turning off nagging until we feel gump is solid enough for that
I think gump's nagging is currently making more noise than signal and this is hurting our ability to come across as helpful instead of annoying. I propose to turn off nagging until we fix this, we are the only one making changes to the metadata anyway, so there is no much point in that. WDYT? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
