Forum OpenACS Development: Why not have an open cvs repository ?

1: Why not have an open cvs repository ?

Posted by Domingo Alvarez duarte on 05/20/01 02:13 PM

In my point of view I think that all of us when testing the actual
openacs4 and meet an error or look at some package code try to figure
out a possible soluction, sometimes we do some changes to test or to
permit the installation go one step further, but that small
modification remain only with you because you don't have access to the
repository without burocracy.

Why not have a second cvs repository with open access where we can
commit it freelly, of course that repository will not have any
guarantee or assistance other than the actual users voluntee.

And the actual package owners can have a look at it time to time and
see if there is any valid contribution that can be used in the
official cvs distribution.

I think that with this politics the port efort will be impulsed a
bit more faster.

2: Response to Why not have an open cvs repository ? (response to 1)

Posted by Don Baccus on 05/20/01 03:21 PM

What is wrong with your e-mailing the package owner if you fix a problem? You're suggesting that package owners take the time to routinely scan a second repository just in case someone might've fixed a bug for them. What a waste of time! You're suggesting that other people spend more time monitoring possible fixes you might make rather than have you take the time to write a simple e-mail message.

I've said it before and I'll say it again: COMMUNICATION is the key to making a project like this succeed.

If you're making local bug fixes and not informing one of your fellow OpenACS 4 porters, then you're not communicating.

It's MUCH more efficient for YOU to e-mail a package maintainer in a case like this rather than expect everyone else to be checking a second repository for bug fixes, figuring out how to merge them with their own work (which undoubtably will have progressed in the interim since they weren't informed that there'd been a bug fix) etc etc etc.

Domingo ... with all due respect I get the impression you want freedom to work on the project without accepting the responsibility of communication. For instance, you still haven't e-mailed me as to whether or not you're interested in finishing porting some of the packages you started on a couple of weeks ago. I've asked you a couple of times. Check the status page, there are several slots there with "DomingoA?" because I don't know if you're actually planning to work on these or not.

You need to COMMUNICATE. It's not about beaurocracy, it's about working together as a team.

3: Response to Why not have an open cvs repository ? (response to 1)

Posted by Domingo Alvarez duarte on 05/20/01 06:05 PM

Maybe I'm misunderstood, let's get that opportunity to explain
it better.

Look I know that most people work hard to make this project goes
forward, but as we can see some of us don't have time or want be
responsible for a project or part of it that doesn't mean that
some of us can't coloaborate ocasionally with some partial work.

I'm not sayng that communication is not a good thing.

Let's describe my personal behavior:

I want to see this project goes forward, even because I want
to use this software.
I have to learn a lot of things, how the overal data model
works, each package funcionality, .....
Sometimes I get an idea or for some reason I want to see way
some part of the system is not working, so I use that
motivation and start making some code ports, but when I find
something taht I can't understand I stop it and start studing
that matter and maybe I get lost on that and don't get back
on it for a while.

Let's suppose that if I could put that work that is not
finished in some place that someone else could see it and
manipulate it as well maybe when I get back on it could I
get part of it done, corrected.

In the other way that work could be lost because probably
when I get back to it someone else released another version
that works or I loose my interest at all.

If we look at the port status we saw that several people
have appointed to do something but probably for several
life reasons they don't commit their partial work to don't
break the main repository or because they aren't happy
with what they have done, I readed several times people
saying that some part is almost done but I don't see it
on the repository.

A thing that I'm trying hard learn is that the perfection
doesn't exist and is a key point know when to stop.

With the above what I want say is that if all the team could
have a place to commit partial work to expose to the others
probably they will get more feedback than hidden it till
some working point.

And if they want and only if they want they can see if someone
did some work on it that can help then.

On the other hand if someone is going in the wrong direction
maybe that can be discovered sooner and save precious human
life time.

4: Response to Why not have an open cvs repository ? (response to 1)

Posted by Ben Adida on 05/20/01 09:47 PM

Domingo, what you're suggesting sounds very pleasant in
theory. It would indeed allow people to freely explore their own
paths without the burden of a centralized repository.

The problem with this approach is related to Metcalfe's Law: the
complexity of a network grows with the square of the number of
nodes. After all, if you want to have a repository of "uncommitted"
changes, I suspect you'll still want that code to function as a
whole, otherwise it's useless. So you'll need to set some
standards for what code can be checked in, maybe standards
not as stringent as those we use on the core tree. Then
someone else will come along and decide that they want more
freedom than you are offering, and branch yet another tree. And
eventually, we have to coordinate N source trees, a coordination
which has a complexity of N*N.

Organized work means some level of flexibility is lost. The
open-source model and the relatively open CVS policy we have
makes this project quite flexible already. Making it any more
flexible would make the overhead of coordination significantly too
high.... Not to mention that you are suggesting (as Don points
out) that this overhead should be handled by the module
owners, who are already the bottleneck!

Now, what you may be suggesting is some sort of source code
control that would be more hierarchical, meaning where module
owners can delegate some chunks of their code to people below
them... much like Linus does with the Linux source tree. I think
that if OpenACS were a larger project, this would be interesting.
Given that the scope is relatively limited, I think the overhead
outweighs the gains here.

5: Response to Why not have an open cvs repository ? (response to 1)

Posted by Don Baccus on 05/20/01 10:58 PM

We certainly can do some delegation, there's no reason why Domingo (or anyone else) can't e-mail a package owner with an offer of help. If that owner wants to accept the proferred help, we can easily make Domingo (or whoever) a committer for that package in the real CVS tree.

The main reason folks don't commit partial work, Domingo, is that they're not done yet. As package owners, most are working alone so there's no particular merit in committing partial work. And others simply haven't begun yet (we have folks finishing school, on vacation, finishing competing work, etc).

I don't see a lot of value in someone skipping from package-to-package, cherry-picking the easy things from each and doing partial commits.

You won't learn anything of value of you do that, and it won't really help the person doing the package port, who presumably is fully capable of doing the easy things themselves.

You'll learn a lot more by taking full responsbility for a small package. You did some work on the "postcard" package, for instance. Finishing that up entails modifying it to use the content repository,
in order to hide the differences between PostgreSQL's and Oracle's handling of long types. Dan's written a document showing how to do this, and if you were to run into problems trying to finish up I'm sure he'd be more than willing to answer any questions or giving you some help.

Finishing what you begin is the mark of a software engineering professional.

6: Response to Why not have an open cvs repository ? (response to 1)

Posted by Pascal Scheffers on 05/21/01 08:15 AM

The answer to Domingos' problem is probably called SDM. Anyone can submit a patch (even to a specific module, RSN), the SDM can then notify the relevant people (or just all commiters, for now).

I do not see how you can get a lower threshold, and still keep it maintainable. I would not like to see a publicly commitable CVS, it's just not worth the bother. A public commit CVS /might/ be useful /if/ the CVS server does not commit the 'public' patch, but simply mails it to the module maintainer - but if that is not a feature of CVS, I'm not going to build it. SDM is (going to be) nice enough.

7: Response to Why not have an open cvs repository ? (response to 1)

Posted by Domingo Alvarez duarte on 05/23/01 10:58 AM

Yes, you are right the SDM is the answer for my ideas, only now ( a few day after reading this) I realize that, thanks for your critics.

In respect to my last comments on changes I've done a patch for then an submited it to SDM and emailed the package maintainners.

There is a saying:

Soft wather, hard rock, so many strokes till a hole.

(well, is more or less a literal translation)

8: Response to Why not have an open cvs repository ? (response to 1)

Posted by Don Baccus on 05/23/01 03:07 PM

Thanks, Domingo, I'm sure that the package owners will appreciate getting direct e-mail.

In the case of general comments, I know that the package owner committed some partial changes because he's leaving for Memorial Day weekend. So I don't know if you found actual problems or just ran into something he hasn't finished yet. By e-mailing him, you'll find out quickly enough (except he may not have e-mail access while on his short holiday!)

I haven't asked that people refrain from committing changes to modules that aren't complete, i.e. thus far we don't have the requirement that package porters not break the existing non-core install while they're working. I think that's reasonable. Any package marked "ported" should certainly install without error (and work). Any package marked "datamodel" should be able to install both its Oracle and Postgres datamodles, but .xql files may be incomplete.

Any package marked "ported" should work for both PG and Oracle, though I've been marking some packages "ported" that still have missing pieces - with a note in the table saying that it's not quite done.

I think this is working well for now.

As soon as most or perhaps all packages have made it through the initial porting stage, I think we'll want to tighten up requirements for committing. In other words, if a package is ported and installing/running fine for PG/Oracle we'll want to avoid intentional commits of new features/bug fixes that break it.

The core is now in that state - if acs-core breaks during a clean install under Oracle or PG it is certainly now a bug.

But only the core's in that state, so I'm not particular concerned about ports-in-progress that don't install at the moment.