> 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 [EMAIL PROTECTED], 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
