Forum OpenACS Development: Why not have an open cvs repository ?
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.
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.
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.
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.
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.
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.
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)
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.