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.
smime.p7s
Description: S/MIME Cryptographic Signature
