I really want answers from everybody, if at all possible, but even Stefan's responses are enlightening. A +0 at best, almost a -1. Interesting, I wanted a sanity check, maybe I'll get one here.
I guess I need to examine why would a rewite (forcing change) be wanted? I think it needs to bring some things radically new. I (personally) have made the effort to learn Python, and it took a while. The Python Gump code is pretty simple, but still takes some time. I can understand that this is a barrier to entry for a lot of Java programers. > > *Python Gump (as a future replacement for traditional Gump) > > +0 as long as it can do everything that the "traditional" Gump can. > -1 otherwise. As it stands it does the core (as I understand it) yet it fails to cope with a few things, and I was hoping to make it 1) It doesn't process outputs (copying jars somewhere, publishing javadocs, publishing junit). This is towards the top of my TODO. 2) It doesn't process projects on workspaces only on modules. 3) It doesn't handle depends on ant tasks (keep meanign to ask you Stefan, 'cos I've seen you use it, what is that?) 4) I am sure there are some other subtle differences. Otherwise, I feel it does everything and more. (1) I will fix, but I'm not sure about (2) or (3) [partly 'cos I don't see understand them.] The more: 1) [IMNSHO] Easier development entry (even for Java programmers, XSLT isn't Java). 1) A GUI (there are lots of benefits here, some really nice ws/profile visualizations.) 2) Better "check tools", better debugging, and other tools. 3) Statistics, the sky is the limit. (especially if we write to some database, I'm using DBM right now.) 4) Cleaner extension points can be added (for users, like me, who use Gump to do more than just build, but publish/other from inside gump's projects). 5) Easier personalized installation ... daft, but true IMHO. The pain is in the ws/profile configuration, and Python Gump helps the users get inside it easier. 6) More OO (if far from perfect) and open for extension/customization. > I won't find the time to learn enough Python to jump into coding so I > can't be +1. I've already had my share of code contributions to the > "traditional" Gump and expect to keep supporting it. This I'll leave until the future. > > *Python Gump using Forrest > > I don't care at all, honestly. Do you run Gump personally/locally, or do you run local custom Gumps? In short -- do you run it remotely and have it communicate to you via HTML(/RSS)? Do you want HTML output (whether it is forrest or XYZ that helps produce it?) > > *Gump Statistics (as a tool for automatically communicating > > reuse/reliability/robustness, etc.) > > Depends on the kind of statistics. I'm really concerned about > reliability/robustness values computed from Gump failures. Ah, really really? Cool, do I have something to entice you? I think statistics (along with easier debugging) are what drove me to want a new Gump (or one I could understand/maintain). I agree 100% that reliability/robustness values are needed. Are you game to help me with thoughts on what these ought be, and how to determine them, and algorythms for them? I consider this a key constribution Gump can make to OSS, a dispassionate view of a project for folks to consider in order to make "build verse buy" (i.e. re-use) decisions. If there were two choices, perhaps to help them pick one that has reached greater maturity. I'd also like statistics to show "activity" (at CVS level I guess). I'd like statistics to show "responsiveness" (to problems). FOG Factor is simple "successes - (failures + prereq failures)", but it might be ok (over time). I recall the archives having a richer algorythm, but I think this one is an adequate start. BTW: What bugs me is if product X changes it's API (or fails to run unit tests) and hence breaks innocent product Y, then Y gets the bad mark. If X is then stagnant/unresponsive, Y gets slammed. I don't see a way that Gump can detect it was X that broke Y, and not Z. Now I realize that Y will eventually move off X, but that fact won't be captured in stats, which is a shame. Still, I feel better some information than no information, we can improve/mature it over time. And, oh yeah, I consider statistics as subversive marketing for good products. ;-) ;-) > > *Gump and Ruper (using Ruper to download packages) > > I'm not sure whether Ruper can help a lot when many of the installed > packages require you to click through a license. Good point, noted. But what of the outputs of Gump that are redistributable. > > *Distributed Gump Trees (also using Ruper to download upstream Gump > > outputs) I run Gump on my stuff, but I have to build much of Jakarta first, and that is tough on my limited resources. If I could automatically (via Ruper) download last night's Gump'd outputs from Jakarta, then I'd be "in pretty good shape" for less. Say I did this, and produced my own outputs. Say others fed of my repository and/or Jakartas, and on. A tree of nested gumps. > > *Gump Documenter (as a tool for communicating the OSS map, and > > promoting) Mapping out the dependencies in the OSS world, to document it. Showing dependencies, dependees ... perhaps showing history of this. I think there is extreme value in the project descriptors (I'm sure you agree here, you invest so much time in them) and I think we need to slice/dice that metadata to present it to humans for perrusal. > I don't think I understand these 8-) > > > *Promoting more gump projects in public Gump (do resources exist, > > will the 7+++ hours grate on Stefan?) > > *Promoting more public/private/personal Gumps. > > *Promoting more OSS Gumps (e.g. on SF.net. on Java.net, etc.) > > Marketing has never been my business and will never be. +0. Ok, so the flip side. What say folks did this, and the main gump became a 15+ hour build. How would you be affected? Would you stop running Gump, and use rsynch/Ruper/other to get jars from public? Would this be bad for you? (I guess I don't know what do you use Gump for. Do you gump your own private projects?) Thanks for your time/insights Stefan. regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
