Forum OpenACS Development: Anybody know anything about Bonsai?

Posted by Talli Somekh on 04/18/01 11:11 PM

Does anybody have any opinion about Mozilla's Bonsai (http://bonsai.mozilla.org)? It seems like a decent system for doing massive open source development. While the OpenACS port may not be called massive, I kind of like the idea of having some real structure to the dev effort. Perhaps something like this could be built into the SDM?

Of course, this brings up the larger issue of how this effort will be organized beyond Joe gets X module. For instance, Roberto is getting hammered with OpenACS 3.2.5 and the docs (btw, thanks Roberto) so it seems that there may be a better way of doing this than having a single person receive and commit patches. This sounds like a vaguely familiar thread of a discussion, so if someone can direct me to where I can learn more about how the community will deal I'd appreciate it.

I don't think that I'm in a particularly good position to make suggestions, much less demands (but did that every stop me before? Nooooo!) so I will leave it to the "experts" to do so.

Experts, do you have any comments?

tal

2: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Patrick Haggood on 04/19/01 01:21 AM

Um, Sourceforge?

3: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Talli Somekh on 04/19/01 01:26 AM

Um, someone else's server? Be nice to keep it on OpenACS.

Can you give any better answer?

tal

4: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Roberto Mello on 04/19/01 01:39 AM

What we have been discussing -- and this is by no means a definitive statement on how things are going to be done; Don is the one who can officially announce this, since he's the one leading the 4.x effort -- is something like this:

- Modules will have owners, or coordinators

- Each module will have a space in the CVS tree

- The coordinator can assign other people to work on the module, and they will be given permissions to the appropriate module on CVS.

- Each module will be in SDM, to track bugs, issues and TODOs.

- Patches can be submitted through SDM (hopefully, by then SDM will have the capability to associate a patch with a bug. Who wants to tackle this now?)

- Each module will take care of its documentation

- I will be coordinating the efforts of the general documentation, but won't do it alone. Others have already volunteered to help.

We already have access control lists setup on the openacs-4 CVS tree. Things are coming along, and it's good to see suggestions. Keep them coming.

Having a query interface to CVS (e.g: Bonsai) would be interesting, but I don't see how that would help us much right now. We need people to port, document and test, really.

5: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Patrick Haggood on 04/19/01 01:44 AM

Which is why I suggested SourceForge, for now. I love to have a sourceforge-like package in ACS - but as I'm still about two days away from the end of my two-week bootcamp ( in fact, typing this in when I should be finishing up schedule-procs.tcl) I can't say today if I'd be me championing that thing. To that end, Sourceforge has all the features in place to support massive open source dev right now.

Borland's Delphi 1 was written in C++. Delphi 2 was written in Delphi. And so it goes...

6: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Richard Li on 04/19/01 04:04 AM

Bonsai is cool. We looked at using Bonsai for ACS, but it requires a lot of hacking and expert CVS knowledge. From the Bonsai source page:

Note: the source code to Bonsai is not pretty. It won't be easy to get it working at your site. See the README file within the Bonsai sources for more extensive disclaimers and apologies.

7: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Don Baccus on 04/19/01 05:33 AM

To that end, Sourceforge has all the features in place to support massive open source dev right now.

The key in putting together a sound software project doesn't lie so much in the simple tools like sourceforge (or the SDM) provide.

It lies in effective people management, scheduling, decomposition of the problem, etc.

Things are moving slower than people would like. Well...that would be every bit as true if we moved to sourceforge.

Get thee to the status page and tell me, please, how hosting at sourceforge would help Ben get the query dispatcher ready to go (nearly done) or Kapil get the query extractor done.

The delay isn't due to not having a canned website, it's due to not having specific pieces ready so we can turn folks loose. Ben's been ill. Kapil's been busy with stuff. Roberto's been busy with stuff. How would hosting at sourceforge increase Ben's productivity, crippled by a very severe cold? "cvs commit" isn't what's been holding him back - he can do that at openacs.org. "quit gacking my lungs on the floor" has been his problem. Sourceforge doesn't help there.

I don't mind impatience, and actually I must apologize for the fact that we didn't have the time or understanding to set the infrastructure in place *before* starting out. That was a mistake. I'm thinking that perhaps the month of April should've been spent putting infrastructure quietly in place, in order to avoid raising folks expectation that things were ready to move like lightning this month.

On the other hand, I had no idea that the pool of available helpers would be so large. We had three or four available for the original ACS->PG port. Many are here because of changes in aD, and you're all welcome, but gee ... we're still kinda rolling with the wave, here. Our little project resting on a glassy sea is starting to feel like a large number of people looking to us to lead them out of a hurricane.

I know folks are tired of my asking for patience, but ... unless someone else can organize it and run it full-time, you're going to be stuck with part-time (15-20 hours a week on my part) leadership. If someone out there has project experience and a budget that would let them run this project full-time with no distractions - hey, e-mail me!

That's life. If you want 60 hours a week leadership financial input would be more than welcome :) I'm kidding, but let's not forget the fact that most of us have other things to deal with than OpenACS and that this include Ben and I.

8: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Michael Feldstein on 04/19/01 04:16 PM

Actually, I've been amazed with how quickly and transparently the project has been moving, all things considered. Compared to the level of transparency we've gotten used to with ACS Classic, we're way ahead of the game. Compared to the Mozilla project (an admittedly much, much more massive project), we're moving along at a good clip.

When I look at the "progress" page in file-storage (which has been updated very regularly), I see many, many modules which nobody has yet signed up to port. It seems to me that the most efficient way to move this project forward is to get people signed up as leads on modules and have them starting to look at the code NOW while we're waiting for core components to be completed. We don't need an enhanced system to do that.

9: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Talli Somekh on 04/19/01 07:01 PM

Don, I'm sorry if I offended. I will be the last person to stand in
the way of any development work or to criticize the amount or quality
of work you've done with OpenACS.

My question was more directed to whether anybody had any experience
with another open source package that might make things slightly more
bearable for the core team. Roberto answered my question as to process
and logistics, and I would like to thank him for that.

Again, I intended absolutely no offense or question anybody's work.
Sorry if I presented it that way.

tal

10: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Don Baccus on 04/19/01 08:12 PM

I wasn't offended. I've been feeling as frustrated as everyone else. It's natural for folks to feel frustrated when things drag and they have no control over that dragging - we all feel it. Ben felt it when he came down with his very bad cold last weekend - because he couldn't control that, and he was ill to the point where he couldn't work for a day or two on the query dispatcher. On and on.

The good thing is that once we get past the bottlenecks listed in the status page we should rarely run into situations where everyone has to sit on their hands waiting for one person to complete a piece of work.

As far as more structure and tools, I do hope to put some time into a project page over the weekend.

11: Response to Anybody know anything about Bonsai? (response to 1)

Posted by Pascal Scheffers on 04/19/01 10:16 PM

 - Patches can be submitted through SDM (hopefully, by then SDM will
have the capability to associate a patch with a bug. Who wants to
tackle this now?)

Roberto, I'd like to take that up. I have looked at the sdm datamodel, doesn't need too much help to implement something very usable and flexible, one table should do the trick. Associate 'patch-with-bug' is also going to mean associate 'feature-rq-with-patch' and a patch should be able to 'fix' several entries in the BaF table.

I have some ideas about the user interface, the simplest would probably be to add check boxes to the 'Open Bugs and Features' page and, obviously, a submit patch button. I don't know about how fine grained the permissions should be, probably identical to the 'submit patch' policy. I can do it this weekend.