You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/03/08 06:49:13 UTC
[RT] Moving gump forward
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.
Re: [RT] Moving gump forward
Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
> Stefan
>
> Good topic, thanks for raising it, it is time.
Me or Stefan?
>>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.
>
>>[...]
>> Gump social maintenance costs are still too high on the gumpmaisters
>>and not well distributed horizontally across the various projects.
>
> Stefano, I concur with your observations, and like your proposals, but I
> think we (as a group) keep overlooking one main thing. Gump is a social
> experiment but we keep using the techie's golden hammer -- more
> technology -- to try to solve it. Making things easier for users who don't
> care about what we do is just going to make it easier for them not to care.
> ;-)
I strongly disagree with this. In fact, it's largely the opposite:
nagging them precisely will make them care. But from that point on, it's
our responsibility to make their life easier in finding a resolution for
the problem.
This can be solved with a better gump system and better (higher S/N)
data presentation.
> We have a social experiment, yet we've (so far) failed to exercise the
> social options. The Gump team know OSS, they know (as good as anybody) what
> drives folks, what motivates, what inspires. Even though we accept that
> nobody can engineer this, we can attempt to leverage it & work with it.
>
> Right after I posted to commons-dev about Gump, and it's aspirations to
> judging health, we had one gentleman go to the trouble of digging out the
> algorythm for FOG from Gumpy CVS, evaluating it, and submitting a JIRA entry
> (which I agree with, BTW). That is effort, that is motivation. The loss of
> "team pride" (maybe) of having their FOG factor halved was a motivator.
I agree. FoG could be a big factor in creating the itch to scratch...
but it could also be a potential killer if not considered "fair".
And my experience says that no matter what heuristic, somebody won't
like it if you are using it to judge them.
> I think Gump needs to get out there, go in-your-face public. Now that we are
> TLP we have a forum to get messages out (gump.apache.org) but we need to
> acquire traffic & work with existing public forums. We ought use community@
> [or similar] and Peas-n-Carrots (& Planet Apache). I'm no marketeer, but I
> think we need to market Gump results -- not market Gump [although that might
> come], but the results. Some [RT] style ideas:
>
> - We need to post (weekly?) to community@ the top FOGs, top improvers and
> bottom FOGs. We need to be public about which projects are strong, which are
> upcoming, and which are failing w/o attention. It is fine to generate a WWW
> site of results, as we do, but we need to live-and-breath those results,
> make them reach out and touch people.
I'd be +1 to this, but only when the list I see reflects the reality I
perceive. Currently, the state of Gump shown by the figures is much
better than the state of gump that *I* personally picture in my mind.
Admittedly, with my cocoon bias, I'm a little frustrated because cocoon
is by far the project with more dependencies, so it's the hardest to
tackle, but exactly because of that, we can't state that gump has
bootstrapped itself until we reach that point (and we did once in the
past, but than the system failed to keep it up, for whatever reason)
> - We need to get to a point where Gump is the first place somebody comes in
> order to determine if they wish to use a new product/package. A conversation
> around "why would we introduce a product with a FOG of 0.1 when we are at
> 1.5?" ought be common.
that would be cool, yes, but again, potentially very self-replicating: I
mean, it's like the first-10 sourceforge effect: the popular ones become
even more popular and the power-law slope increases... I'm not sure I
want that.
> - We need to make FOG (or Gump score, whatever) an active thing. Perhaps
> PMCs ought evaluate FOG before allowing a project out of sandbox, out of
> incubation. [Note this is *RT*, not proposal].
If I know the foundation well enough, this is hardly ever going to
happen, for the reasons I expressed above: no matter what heuristic you
find, those who get a bad score and disagree with you will give you a
very hard time.
> - I think we need a nice 'I rate with Gump' icon, that dynamically links to
> their score.
>
> [Before we do, we need the numbers to really mean something, and to take
> into consideration some key aspects -- depth of dependences, distance
> between two projects -- some Googlesque value of 'links to' (where teams are
> 'rating' each other through usage/referencing.)
>
> Gump stats are in their infancy, and not taking into consideration much of
> the value of the metadata graph. I think we ought add much more to it also,
> like 'friend of' (even if not a dependee). Maybe even add 'who associates
> with' (an individual aspect) -- so we can follow folks we like. I could go
> on and on and on ... and will w/ an [RT] sometime soon, I hope.]
I totally agree that there is a goldmine of data in the dependency graph
and their history of failures.... but as I did with Agora, I think you
can show this without having to resort to numbers directly.
In agora I tried hard to avoid numbers, so that people couldn't say "I'm
better than you", it's fuzzy evaluation, tends to give signal without
creating social friction.
I really don't know how to apply the same to the FoG factor though...
while I think it would be enough to have iconic rating, say
red/yellow/green lights, instead of precise numbers.
> Along the lines of what Stefano said, but adding a little to the social
> aspect:
>
> - Perhaps we ought copy 'affected' projects on nags, so the recipient &
> those affected know who is affecting them. Nags are (right now) too
> personal/private & a team can quietly sit on them. [This said, I think we
> want to push the positives -- values of success -- not try nagging folks
> into action.]
idealy, you nag the offender and you copy the offended. but figuring out
which is which is not an easy task (as I showed in my previous email)
> - Perhaps we 'nag' folks when their FOG goes up into the next level (a
> positive :-) and also when it drops down to another level. Yes, as Stefano
> said, we ought (occasionally) let folks know their status even if things are
> status quo.
Receiving an email like "you are now a friend of gump" is a social
party, but receiving a "we are not friends anymore" would yield very bad
implications if the community has the perception is not their fault nor
they could do anything about it.
you want to avoid the "then screw you, sucker" feeling ;-)
> In summary -- my point is we've not explored the social solutions to the
> Gumpmeister headache, and I'd love to hear other ideas on how we could
> leverage that.
My suggestion is to try to be smarter ourselves before exploring the
"increase fedback energy by fostering ego competition".
That path is a very slippery slope.
--
Stefano.
Re: [RT] Moving gump forward
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
Stefan
Good topic, thanks for raising it, it is time.
> 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.
> [...]
> Gump social maintenance costs are still too high on the gumpmaisters
> and not well distributed horizontally across the various projects.
Stefano, I concur with your observations, and like your proposals, but I
think we (as a group) keep overlooking one main thing. Gump is a social
experiment but we keep using the techie's golden hammer -- more
technology -- to try to solve it. Making things easier for users who don't
care about what we do is just going to make it easier for them not to care.
;-)
We have a social experiment, yet we've (so far) failed to exercise the
social options. The Gump team know OSS, they know (as good as anybody) what
drives folks, what motivates, what inspires. Even though we accept that
nobody can engineer this, we can attempt to leverage it & work with it.
Right after I posted to commons-dev about Gump, and it's aspirations to
judging health, we had one gentleman go to the trouble of digging out the
algorythm for FOG from Gumpy CVS, evaluating it, and submitting a JIRA entry
(which I agree with, BTW). That is effort, that is motivation. The loss of
"team pride" (maybe) of having their FOG factor halved was a motivator.
I think Gump needs to get out there, go in-your-face public. Now that we are
TLP we have a forum to get messages out (gump.apache.org) but we need to
acquire traffic & work with existing public forums. We ought use community@
[or similar] and Peas-n-Carrots (& Planet Apache). I'm no marketeer, but I
think we need to market Gump results -- not market Gump [although that might
come], but the results. Some [RT] style ideas:
- We need to post (weekly?) to community@ the top FOGs, top improvers and
bottom FOGs. We need to be public about which projects are strong, which are
upcoming, and which are failing w/o attention. It is fine to generate a WWW
site of results, as we do, but we need to live-and-breath those results,
make them reach out and touch people.
- We need to get to a point where Gump is the first place somebody comes in
order to determine if they wish to use a new product/package. A conversation
around "why would we introduce a product with a FOG of 0.1 when we are at
1.5?" ought be common.
- We need to make FOG (or Gump score, whatever) an active thing. Perhaps
PMCs ought evaluate FOG before allowing a project out of sandbox, out of
incubation. [Note this is *RT*, not proposal].
- I think we need a nice 'I rate with Gump' icon, that dynamically links to
their score.
[Before we do, we need the numbers to really mean something, and to take
into consideration some key aspects -- depth of dependences, distance
between two projects -- some Googlesque value of 'links to' (where teams are
'rating' each other through usage/referencing.)
Gump stats are in their infancy, and not taking into consideration much of
the value of the metadata graph. I think we ought add much more to it also,
like 'friend of' (even if not a dependee). Maybe even add 'who associates
with' (an individual aspect) -- so we can follow folks we like. I could go
on and on and on ... and will w/ an [RT] sometime soon, I hope.]
Along the lines of what Stefano said, but adding a little to the social
aspect:
- Perhaps we ought copy 'affected' projects on nags, so the recipient &
those affected know who is affecting them. Nags are (right now) too
personal/private & a team can quietly sit on them. [This said, I think we
want to push the positives -- values of success -- not try nagging folks
into action.]
- Perhaps we 'nag' folks when their FOG goes up into the next level (a
positive :-) and also when it drops down to another level. Yes, as Stefano
said, we ought (occasionally) let folks know their status even if things are
status quo.
In summary -- my point is we've not explored the social solutions to the
Gumpmeister headache, and I'd love to hear other ideas on how we could
leverage that.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Moving gump forward
Posted by Michael Davey <Mi...@coderage.org>.
> 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:
[snip]
If Gump knows what dependancies a particular project has, when the
project and each of its dependencies last built successfully and it
knows how to get the source from CVS, it should be possible to list all
the CVS changes that have happened since the last successful build. Of
course, if each gump installation also knows of other gump installations
including the JRE, it might be possible to further reduce the list of
changes by sharing results between gumps.
--
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Moving gump forward
Posted by Stefano Mazzocchi <st...@apache.org>.
Scott Sanders wrote:
>>> My latest try was vindico, an ant-based gump. I got far enough to
>>> see things building and so on, but not far enough to do the
>>> project.xml override/inheritance. I do believe it was a viable
>>> model, the biggest issue being that I was still using java products
>>> to build java products, and Sam had warned me about these types of
>>> things. I only stopped because Adam had started pushing more and
>>> more code into Gumpy, and I liked the idea of using non-Java to build
>>> Java. That, and he was coding much more than I was :)
>>> In short, there are a couple of gotchas with an ant-based gump, but I
>>> think it is completly doable. My other ambitions with vindico were
>>> more what we are talking about today: doing history on all builds,
>>> trying to find who to blame (usually 1 side of a 2-sided interface),
>>> moving more toward some type of continuous integration, federation of
>>> gumps (so that I am only building 4 projects), etc.
>>
>>
>> I think that gump should *NOT* try to reinvent the wheel and simply
>> make sense of what the projects already do.
>>
>> Keep in mind that gump is currently a top level project and we aim at
>> building *EVERYTHING* the ASF does, including HTTPD.
>>
>
> Maybe I am misunderstanding what you are saying or vice versa, but I am
> in favor of sticking with Gumpy, and expanding it to include anything
> that can be built, including C code.
Sorry Scott, then I apologize because I misunderstood you.
--
Stefano.
Re: [RT] Moving gump forward
Posted by Scott Sanders <sc...@dotnot.org>.
>> My latest try was vindico, an ant-based gump. I got far enough to
>> see things building and so on, but not far enough to do the
>> project.xml override/inheritance. I do believe it was a viable
>> model, the biggest issue being that I was still using java products
>> to build java products, and Sam had warned me about these types of
>> things. I only stopped because Adam had started pushing more and
>> more code into Gumpy, and I liked the idea of using non-Java to build
>> Java. That, and he was coding much more than I was :)
>> In short, there are a couple of gotchas with an ant-based gump, but I
>> think it is completly doable. My other ambitions with vindico were
>> more what we are talking about today: doing history on all builds,
>> trying to find who to blame (usually 1 side of a 2-sided interface),
>> moving more toward some type of continuous integration, federation of
>> gumps (so that I am only building 4 projects), etc.
>
> I think that gump should *NOT* try to reinvent the wheel and simply
> make sense of what the projects already do.
>
> Keep in mind that gump is currently a top level project and we aim at
> building *EVERYTHING* the ASF does, including HTTPD.
>
Maybe I am misunderstanding what you are saying or vice versa, but I am
in favor of sticking with Gumpy, and expanding it to include anything
that can be built, including C code.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Moving gump forward
Posted by Stefano Mazzocchi <st...@apache.org>.
Scott Sanders wrote:
>
> On Mar 9, 2004, at 2:27 AM, Stefan Bodewig wrote:
>
>>
>>> BTW: I suspect that <gump could implemented by writting the ant
>>> script on the fly w/o us having to reinvent the wheel.
>>
>>
>> See the antgump proposal in Alexandria - maybe Scott can chime in
>> here?
>>
>
> My latest try was vindico, an ant-based gump. I got far enough to see
> things building and so on, but not far enough to do the project.xml
> override/inheritance. I do believe it was a viable model, the biggest
> issue being that I was still using java products to build java products,
> and Sam had warned me about these types of things. I only stopped
> because Adam had started pushing more and more code into Gumpy, and I
> liked the idea of using non-Java to build Java. That, and he was coding
> much more than I was :)
>
> In short, there are a couple of gotchas with an ant-based gump, but I
> think it is completly doable. My other ambitions with vindico were more
> what we are talking about today: doing history on all builds, trying to
> find who to blame (usually 1 side of a 2-sided interface), moving more
> toward some type of continuous integration, federation of gumps (so that
> I am only building 4 projects), etc.
I think that gump should *NOT* try to reinvent the wheel and simply make
sense of what the projects already do.
Keep in mind that gump is currently a top level project and we aim at
building *EVERYTHING* the ASF does, including HTTPD.
--
Stefano.
Re: [RT] Moving gump forward
Posted by Scott Sanders <sc...@dotnot.org>.
On Mar 9, 2004, at 2:27 AM, Stefan Bodewig wrote:
>
>> BTW: I suspect that <gump could implemented by writting the ant
>> script on the fly w/o us having to reinvent the wheel.
>
> See the antgump proposal in Alexandria - maybe Scott can chime in
> here?
>
My latest try was vindico, an ant-based gump. I got far enough to see
things building and so on, but not far enough to do the project.xml
override/inheritance. I do believe it was a viable model, the biggest
issue being that I was still using java products to build java
products, and Sam had warned me about these types of things. I only
stopped because Adam had started pushing more and more code into Gumpy,
and I liked the idea of using non-Java to build Java. That, and he was
coding much more than I was :)
In short, there are a couple of gotchas with an ant-based gump, but I
think it is completly doable. My other ambitions with vindico were
more what we are talking about today: doing history on all builds,
trying to find who to blame (usually 1 side of a 2-sided interface),
moving more toward some type of continuous integration, federation of
gumps (so that I am only building 4 projects), etc.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Moving gump forward
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 8 Mar 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:
> I'd like Stefan's input on if we allowed a <gump to be like
> <ant|<maven -- to have Gump just build/archive.
It won't work, at least not without duplicating larger parts of the
build file in the gump descriptor.
Gump currently doesn't know where the sources are, some project
definitions compile from more than one source directory.
Many builds contain conditional compilations (like Ant's starteam
tasks will never get compiled in Gump since the - non-public -
starteam SDK is not available).
Many projects produce multiple jars, Gump doesn't know what to put
where.
If we make all the necessary information available to Gump the
descriptor will become as complex as a minimal Ant build file to do
the same thing. People simply won't take the effort to create it, and
why should they when all the information they have to provide already
is available from the build files/project descriptors/whatever.
> We'd loose the ant regression test suite.
Don't restrict it to "my" (it isn't mine, BTW ;-) Ant regressions
suite. The same would apply to Maven or NAnt or GNU make or ...
> BTW: I suspect that <gump could implemented by writting the ant
> script on the fly w/o us having to reinvent the wheel.
See the antgump proposal in Alexandria - maybe Scott can chime in
here?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Moving gump forward
Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
> Leo wrote plenty -- with this just being a snippet:
>
>
>> = The Human Factor =
>>
>>What I really like about gump is the principle that we emulate developer
>>behaviour as much as possible.
>>
>
>
> Yup, me too, I liked it when you posted to Avalon-Dev also. Maybe we need a
> logo of some crazied gung-ho half-blind half-carpel-tunneled geek who just
> can't see a CVS commit message they don't want to tinker with. ;-)
>
> The rest of what you wrote -- made me reconsider my last posting. I'm not
> saying that aspects of Gump aren't broken, and we need just promote, I just
> think we need to promote for those happily using Gump right now. For those
> with simple build systems things really aren't that that bad. I wonder if
> that is the majority or not.
Adam, that's why I dislike those numbers so much: they give a false
impression. Having 60% of the tree built is useless if that 40% is where
the juice is.
Where is the juice? where it is hardest to keep track of dependencies.
Cocoon didn't have a single gump run in 6 months or more.
Focus on fixing that and you'll see how thing change.
> That said, Gump is very sensetive to the build system, and I like the IDE
> comparison/analogy/proposal. Doing a build is a compile plus a jar (plus
> perhaps unit tests/others?). I'd like Stefan's input on if we allowed a
> <gump to be like <ant|<maven -- to have Gump just build/archive. We'd loose
> the ant regression test suite. Maybe we just keep Gump IDE-like simple, and
> say that if you want to 'plug-in' then use <ant. (Yes Leo, I read you blog
> entry ;-)
>
> BTW: I suspect that <gump could implemented by writting the ant script on
> the fly w/o us having to reinvent the wheel.
I think we should focus on using what the projects have. It's harder to
start with, but much more solid in the longer run.
--
Stefano.
Re: [RT] Moving gump forward
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
Leo wrote plenty -- with this just being a snippet:
> = The Human Factor =
>
> What I really like about gump is the principle that we emulate developer
> behaviour as much as possible.
>
Yup, me too, I liked it when you posted to Avalon-Dev also. Maybe we need a
logo of some crazied gung-ho half-blind half-carpel-tunneled geek who just
can't see a CVS commit message they don't want to tinker with. ;-)
The rest of what you wrote -- made me reconsider my last posting. I'm not
saying that aspects of Gump aren't broken, and we need just promote, I just
think we need to promote for those happily using Gump right now. For those
with simple build systems things really aren't that that bad. I wonder if
that is the majority or not.
That said, Gump is very sensetive to the build system, and I like the IDE
comparison/analogy/proposal. Doing a build is a compile plus a jar (plus
perhaps unit tests/others?). I'd like Stefan's input on if we allowed a
<gump to be like <ant|<maven -- to have Gump just build/archive. We'd loose
the ant regression test suite. Maybe we just keep Gump IDE-like simple, and
say that if you want to 'plug-in' then use <ant. (Yes Leo, I read you blog
entry ;-)
BTW: I suspect that <gump could implemented by writting the ant script on
the fly w/o us having to reinvent the wheel.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Moving gump forward
Posted by Leo Simons <ls...@jicarilla.org>.
Leo Simons wrote:
> (unless you write
>> a web application to handle those things directly ;-)
>
> that was, in fact, the idea in the back of my head.
I did some digging. Python seems to be real good for building webapps,
actually. The more I think about it, the more it seems to make sense. I
am going to try and find time (where's all my free time going, lately?
>:() to figure out what this thing should look like, and how it might
actually work, too.
For now I just have a name:
iGump
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Moving gump forward
Posted by Leo Simons <ls...@jicarilla.org>.
Stefano Mazzocchi wrote:
> Leo Simons wrote:
>
>> But since we're going by leaps and bounds right now...we need a
>> wiki-style workflow. Ditch CVS and provide me with an "edit this
>> descriptor" page. The task of finding the right descriptor to edit can
>> be several minutes of work. That should change to several seconds.
>
> Leo: do you realize the potential security implications of this?
sure. What's your comfort level?
If you run gump from a restricted account on a reasonably secured box
(especially a dedicated one with restricted access), and you add some
HTTPS digest auth in front of it (for example), I don't see this as a
big issue.
Its like moving from cvs to svn. A key advantage to the ASF is that not
everyone will need shell accounts. Same applies to gump -- you can give
out basic access to update project descriptors to lots of people.
Changing gump to a wiki-style workflow means changing a whole lot of
things anyway. The security concerns are addressable.
>> = Let's go relational =
>
> My "let's go relational" was for the history data, not for the project
> descriptors.
I know :-D
> Going relational there would buy us only more effort (unless you write a
> web application to handle those things directly ;-)
that was, in fact, the idea in the back of my head. I don't know much
about python-based web applications, but I do know there's stuff called
Zope, Plone, and the like. It might be worth it :-D
>>> Enough brainstorming for tonight.
>>
>> I have more to say, but gotta run right now :-D
>
> keep it coming :-)
I've been thinking more and more about developer workflow. There's not
all that many infrastructure-style tools that have a nice workflow
(IMNSHO). The changing of obscure non-DTD-enabled XML files that are
hard to track down in some cvs repository or worse, in some undocumented
location that you reach over SSH...it is a large part of what makes
software development and system administration painful.
It doesn't neccessarily have to be a fancy GUI (example of a
command-line app that rules: apt), but a lot of things /can/ be hidden.
Jira, confluence, sourceforge. That's what I'm thinking of atm. Nothing
crystalized yet.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Moving gump forward
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> But since we're going by leaps and bounds right now...we need a
> wiki-style workflow. Ditch CVS and provide me with an "edit this
> descriptor" page. The task of finding the right descriptor to edit can
> be several minutes of work. That should change to several seconds.
Leo: do you realize the potential security implications of this?
> = The Human Factor =
>
> What I really like about gump is the principle that we emulate developer
> behaviour as much as possible.
>
> We could just let the metadata point to the sources, do away with ant
> alltogether, and implement an IDE-like compiler. But then gump would be
> able to build lots of things that might fail to build on the commandline.
yes, this is why I'm kinda reluctant to make gump more aware of what's
going on internally. the fact that gump is dumb and proud to be is a
lovely feature, IMO.
> = The friggin' broken buildsystem =
>
> It's not always a classfile change that broke things. In the avalon
> case, for example, the projects that are failing to build haven't seen
> very significant API change. The build itself is broken.
>
> Maybe we should fall back to trying a non-ant build when that happens.
> Is it possible to detect an ant (or maven) failure as opposed to an api
> change? Is it worthwhile to seperate it out.
not unless we analyze the output.
> = Let's go relational =
>
> We want to build a complex, flexible, relational model of all these
> builds. Maybe its just me, but XML doesn't express that too well. It's
> much easier to express some fomrs of "intelligence" in SQL.
My "let's go relational" was for the history data, not for the project
descriptors.
Going relational there would buy us only more effort (unless you write a
web application to handle those things directly ;-)
>
>> Enough brainstorming for tonight.
>
>
> I have more to say, but gotta run right now :-D
keep it coming :-)
--
Stefano.
Re: [RT] Moving gump forward
Posted by Leo Simons <le...@apache.org>.
Stefano Mazzocchi wrote:
> 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.
this is a good one. Summary of some important thoughts so far.
> Gump social maintenance costs are still too high on the gumpmaisters
> and not well distributed horizontally across the various projects.
indeed. Gump as a social experiment takes its toll on the experimentors.
> 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.
you know, I'm inclined to design a 'mock' workflow package here, conduct
tests of people's behaviour, improve the mock, etc. The gump workflow is
*complex*.
Not that I actually know much about user interface testing ;)
> at this point I'll let the discussion start on what should be on that page.
we need guinea pigs :-D
= Workflow =
let's try to describe the optimal gump workflow. I've found (in
describing this to other people), that the current gump workflow is much
like working on (someone else's) spagetti code. It seems we need the
equivalent of "code insight" features.
How would that work? Send me an e-mail saying my project failed to
build. Include a link that will take me to the (highlighted) part of the
build output that seems to be the problem. Make references to classnames
'n stuff clickable. Clicking on a classname (ie as spit out by the
compiler when there's a problem) takes me to the build log of the
dependency.
If another project failed because of my change, send me an e-mail
pointing to that failure (those failures). Indicate the classes that
seem to be the problem. Tell me when the project started failing and
provide me a ViewCVS link that indicates the class that is apparently
causing problems for the other project.
As a first step, let people look at the cvs history themselves.
Automation seems nice, but there's also a lot that can be done just by
making the UI as powerful as possible.
But since we're going by leaps and bounds right now...we need a
wiki-style workflow. Ditch CVS and provide me with an "edit this
descriptor" page. The task of finding the right descriptor to edit can
be several minutes of work. That should change to several seconds.
= The Human Factor =
What I really like about gump is the principle that we emulate developer
behaviour as much as possible.
We could just let the metadata point to the sources, do away with ant
alltogether, and implement an IDE-like compiler. But then gump would be
able to build lots of things that might fail to build on the commandline.
= The friggin' broken buildsystem =
It's not always a classfile change that broke things. In the avalon
case, for example, the projects that are failing to build haven't seen
very significant API change. The build itself is broken.
Maybe we should fall back to trying a non-ant build when that happens.
Is it possible to detect an ant (or maven) failure as opposed to an api
change? Is it worthwhile to seperate it out.
= Let's go relational =
We want to build a complex, flexible, relational model of all these
builds. Maybe its just me, but XML doesn't express that too well. It's
much easier to express some fomrs of "intelligence" in SQL.
> Enough brainstorming for tonight.
I have more to say, but gotta run right now :-D
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org