On Thu, 26 Feb 2004, Adam R. B. Jack <[EMAIL PROTECTED]> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
