You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Ceki Gülcü <ce...@qos.ch> on 2004/12/01 16:12:13 UTC
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [vote] turning off nagging until we feel gump is solid enough
for that
Posted by Stefano Mazzocchi <st...@apache.org>.
Stefan Bodewig wrote:
> On Thu, 2 Dec 2004, Eric Pugh <ep...@opensourceconnections.com> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [vote] turning off nagging until we feel gump is solid enough
for that
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 2 Dec 2004, Eric Pugh <ep...@opensourceconnections.com> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: [vote] turning off nagging until we feel gump is solid enough for that
Posted by Eric Pugh <ep...@opensourceconnections.com>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [vote] turning off nagging until we feel gump is solid enough
for that
Posted by Stefano Mazzocchi <st...@apache.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [vote] turning off nagging until we feel gump is solid
enough for that
Posted by Ceki Gülcü <ce...@qos.ch>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [vote] turning off nagging until we feel gump is solid enough
for that
Posted by Stefano Mazzocchi <st...@apache.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [vote] turning off nagging until we feel gump is solid enough for that
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
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: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [vote] turning off nagging until we feel gump is solid
enough for that
Posted by Ceki Gülcü <ce...@qos.ch>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [vote] turning off nagging until we feel gump is solid enough for that
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
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: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org