gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Processing based off statistics
Date Fri, 27 Feb 2004 08:01:13 GMT
On Thu, 26 Feb 2004, Adam R. B. Jack <ajack@trysybase.com> wrote:

> It occurs to me that folks (like the Avalon team) are possibly
> frustrated by the nags they are getting, but (despite Leo's request
> for volunteers) are not finding time to fix them. I hope (like some
> folks on the forrest list) they aren't getting annoyed at the nags,
> but I could understand it if the are. As such, some thoughts
> occur...

In the specific Avalon situation I beg to differ.

If we all had commit access to the descriptors, I'm almost certain the
avalon project wouldn't fail any longer.  There are other failures in
avalon due to properties not being set correctly or wrong paths.

If Leo can't find help inside the Avalon team we may be better of with
moving the descriptors under Gump control.  In Gump's module the
Avalon committers can still manage them, there are just more hands
available to fix them, not less.

> 1) What are your thoughts to these two above? Any objects to backing
> off nags if ignored or (like w/ jUDDI, just deferred?)

If the nags are annoying, committers for the project can simply turn
them off.  Same for deferred nags.  After all all committers are able
to remove the nag elements.

This doesn't apply to externally hosted projects, see mockobjects.  In
this case we should disable nagging completely - on request.

> 2) Any other ideas for things we wish to make dependent upon last
> state?

I'm not sure I follow you here.

Stefan

Mime
View raw message