gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] Moving gump forward
Date Mon, 08 Mar 2004 05:49:13 GMT
RT stands for random thoughts. It's a cocoon tradition but it was 
already used overhere in the past (like to spin off Gumpy for example).

RT is where you throw you thought in the mix and see what happens. It 
could be the best thing or the most silly idea. it doesn't matter. It's 
a community brainstorming and you are allowed to get wild without nobody 
to worry about getting stuff done or implemented.

Funnily enough, RTs are the threads that get most of the design done... 
sort of like RFCs started as "request for comments" and now they are 
considered as standards.

Funny how community dynamics evolve.

Anyway, here we go.

                                  - o -

NOTE: I consider traditional gump dead, so when I say "gump" I mean 
gumpy in this context.

Gump is an incredible idea and has no equivalent thing anywhere else. 
Still, it requires lots of energy from the gumpmaisters to keep it running.

Sam did for a while, then let go and things are starting to be back on 
track now, but the energy required is, IMO, too much and it hasn't 
reached the point where stability is considered and friend-of-gump-ness 
is taken for granted.

We need to get better at this or everytime we let go the system 
collapses again.

So, my first point:

   Gump social maintenance costs are still too high on the gumpmaisters 
and not well distributed horizontally across the various projects.

How do we fix that? Here is my take:

   Better signal/noise ratio (show me where the problem is!!)
   Higher quality nagging (let gump figure out whose fault that is!!)

                                   - o -

Better S/N ratio
================

As I said previously, gump is just too verbose. Beside gump own 
developers, Gump is the kind of web site that you look at only when 
there are problems.

So, first big concept: our major user target is people that got nagged!

We *MUST* focus on making *their* life easier. They don't care about how 
much percentage of our codebase was built, they don't care about a FOG 
factor, they just want to stop that annoying nagging.

This is *OUR* leverage.

Nagging triggers their use of their energy, but we must make sure that 
the path to fixing the nag is the least resistant possible.

So, here are my proposals:

  1) You should also be nagged if our project hasn't been built because 
of dependencies reasons for the last week.

  2) we must make sure that people's nagged uncomfort grows with the 
amount of dependecies they break! Note that giving them a number doesn't 
work, you have to build up the entire list!!! you have to make them feel 
really uncomfortable. The more uncomfortable, the more energy they are 
going to push into the system to keep this from happening!!! or the 
faster they are going to resolve an issue that emerges!!

this increased obnoxiousness of nagging must also result in better web 
pages, because, after we push them to tackle the problem, at this point, 
we want to help them figuring out what's wrong and what they can do to 
fix it.

So, scenario of use is:

  1) you get nagged with a very nasty email that lists all the projects 
that you screwed with that build failure

  2) that email contains a link to the page that you should go to to 
find information on how to solve the issue

  3) that page should contain all the information about your project. 
dependencies and dependees, status, build message, historical stats and 
various description

this scenario is for our regular gump users.

Another scenario is for gump maisters:

  1) you want to know what is causing more harm (hotspots)

  2) so you go to a "summary" page that should give you that information 
and point you to the hotspot projects

at this point I'll let the discussion start on what should be on that page.

                                     - o -

Better nagging quality
----------------------

You receive a nag email. This is how most of the people get in contact
with Gump in the first place. They want to understand WTF since their
projects compile just fine in their local machine and nobody is
complaining (this indicates a dependency failure).

Now, the *first* question that person is going to look for data to
answer is: what broke me?

This is wrong!! Gump should be designed to nag the offender and copy the
offended, not nag the offended and ignore the offender!!!

If project B depends on A and changes on A broke B, you should be
telling A and copy B, this is, socially, much more efficient because who
did the action that caused the reaction would be much more willing to
solve the issue since he/she feels responsible for it.

Nagging the offended is suboptimal, because the person has to:

   1) go back to gump and understand what broke them
   2) make sure that's right
   3) pass the nagging along (which included politeness problems)

This process is too socially expensive and people tend to receive nags
and ignore them instead of going fixing them because the social energy
required to ignore nags is lower than the one required to fix the issue.

And this is due to a problem in how gump is designed.

Now, how can we solve this?

The first thing to note is that gump doesn't know anything about the
semantics of the operations it calls. in fact, every gump operation
returns a boolean: true for success, false for failure.

Gump metadata includes dependencies. Let us assume that gump project
metadata included dependencies on project *AND* a timestamp on what it
the moment in time against with the project is working on.

This timestamp could be a tag, a date or a release version: anything
that allows us to restore that particular state from the code repository
(CVS in our case).

So, this suppose that we have two projects, A and B, B depending on A in
version 1.3:

      Project A --------------(1.2)--------- (1.3)--[HEAD]
                                                 \
                                                  \
                                                   \
                                                    \
      Project B ------(3.4.23)----------(3.5)-------[HEAD]


Now, I think it's possible (even if computationally expensive) to 
understand exactly what commit broke the build and to nag the exact 
person and the community and copy all the offended people.

That's how it should work:

  checkout A[HEAD]
  build A[HEAD] and save bolean result in A1
  checkout A[STABLE]
  build A[STABLE] and save bolean result in A2
  checkout B[HEAD]
  build B[HEAD] against A[HEAD] and save bolean result in BA1
  build B[HEAD] against A[STABLE] and save bolean result in BA2

here is all the possible outcomes

    A1 | A2 | BA1 | BA2
  ----------------------
    1    1     1     1  -> B is fine
    1    1     1     0  -> A fixed B
    1    1     0     1  -> A broke B
    1    1     0     0  -> B is broken
    1    0     1     x  -> B is integrated but A stops build
    1    0     0     x  -> B is not integrated and A stops build
    0    1     x     1  -> B is built locally but A stops integration
    0    1     x     0  -> B is locally broken and A stops integration
    0    0     x     x  -> A stops B

The only slight problem with this approach is that a project with n 
dependencies has to do

  b = 2*n + 2^n

builds, this is how the number grows

  n = 1 -> b = 4
  n = 2 -> b = 8
  n = 3 -> b = 14
  n = 4 -> b = 24
  ...
  n = 50 -> b = 1125899906842724

for those not familiar with exponential growth, it's enough to say that 
if the build took a minute it would take gump 2,5 billion years to find 
out what broke the build.

This seems rather hopeless, but this is just pure bruteforce.. I'm sure 
there are way to optimize this.

Enough brainstorming for tonight.

Enjoy.

-- 
Stefano.



Mime
View raw message