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 18:36:15 UTC
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: 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