gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: Processing based off statistics
Date Fri, 27 Feb 2004 16:34:51 GMT
> 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.

It is such a balance isn't it, we wish the community to get involved, but
other areas of the community suffer if one doesn't maintain it's metadata.
Gump metadata has a bit of a learning curve, and until we can make it
totally trivial (or self explanatory) perhaps we need to help folks get
started, get working, and hope they tweak it when/if it breaks in the
future.

Even though today I saw a breath of interest on dev@avalon, I propose we
move it to Gump CVS. I see no reason (with our open commit policy) that any
descriptor for Apache stuff needs to be outside of Gump CVS.

> > 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.

I was hoping for a little more than on/off.

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

Agreed.

I tried to make projects w/o nags generate nags [a single mail] to the Gump
list, so we could process things like broken packages, etc. I need to debug
why that isn't occuring.

> > 2) Any other ideas for things we wish to make dependent upon last
> > state?
>
> I'm not sure I follow you here.

If the last state was 'failed', and perhaps if no modifications occurred
(and I still wish to see if I can figure out when a descriptor changes) then
perhaps we set -debug or something.

I was wondering if folks could think of other such examples of modifying
processing based off statistics or state, etc.

regards,

Adam


Mime
View raw message