Processing based off statistics

["Adam R. B. Jack" <aj...@trysybase.com>]

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

If a project has spent a certain period (N runs) in a given state, it is
probably wiser to nag every M runs, not every run -- especially if the
project/module has not been updated. Also, what about automatically setting
'-debug' on runs that failed last run?

I suspect other such logic could become interesting once this is available.

1) What are your thoughts to these two above? Any objects to backing off
nags if ignored or (like w/ jUDDI, just deferred?)
2) Any other ideas for things we wish to make dependent upon last state?

regards,

Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com

Re: Processing based off statistics

[Stefan Bodewig <bo...@apache.org>]

On Fri, 27 Feb 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:

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

Absolutely.

The thing to keep in mind is that for Apache projects the community
has full access to a descriptor that lives inside the Gump module.  So
the community that can fix things includes more people - and all
people who could fix things when the descriptor is in a more private
module.

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

I see.

I'm a bit unsure as to what we can do here since we'd need to know
whether the nags simply get ignored (in which case there is no point
in doing anything but turning them off) or just postponed.  Is there
any automatic way to tell?

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

Seems to work now 8-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Processing based off statistics

["Adam R. B. Jack" <aj...@trysybase.com>]

> 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

Re: Processing based off statistics

[Antoine Lévy-Lambert <an...@antbuild.com>]

Nicola Ken Barozzi wrote:

> Stefan Bodewig wrote:
>
>> On Thu, 26 Feb 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:
>
> ...
>
>> 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.
>
>
> I agree.
>
> If a project fails to act (IOW there is general inaction, not just 
> some errors that they try to fix) on a descriptor when there are 
> failures, we should reclaim it. In the case of Apache projects this 
> holds even more, as all committers have access to the Gump module.
>
+10 Nicola and Stefan

Antoine

Re: Processing based off statistics

[Nicola Ken Barozzi <ni...@apache.org>]

Stefan Bodewig wrote:

> On Thu, 26 Feb 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:
...
> 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.

I agree.

If a project fails to act (IOW there is general inaction, not just some 
errors that they try to fix) on a descriptor when there are failures, we 
should reclaim it. In the case of Apache projects this holds even more, 
as all committers have access to the Gump module.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Processing based off statistics

[Stefan Bodewig <bo...@apache.org>]

On Thu, 26 Feb 2004, Adam R. B. Jack <aj...@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