Forum OpenACS Q&A: New versions vs. new packages
to insert some new tickets, switched to ticket tracker lite. In going
through the CVS tree, I now see that there's a "bug tracker" package,
which I'm still looking through, but which seems to overlap at least
partly with the existing ticket-tracker* packages and/or the sdm.
So we now seem to have three ticket-tracker packages, two forum
packages (bboard and forum), two photo album packages, two survey
packages, and I believe that there are some other examples as well.
Not only is this a bit confusing for newcomers (and not-so-newcomers),
but doesn't this negate the whole idea of upgrade scripts for existing
users? Is there any explicit (or implicit) policy about incrementing
versions vs. creating a new package?
I realize full well (despite what Joel Spolsky says) that it's often
better to throw away an existing design than to try to improve it.
But I wonder if we (as a community) have gone a bit too far in that
direction, and are throwing away more than we're keeping.
This also demonstrates, at least to me, the need to keep track of the
various packages that are available, both for marketing purposes
("look, we can do XZY!") and for OpenACS admins around the world who
want to enhance their sites. zope.org does a so-so job of this,
categorizing products in a general way but not really indicating which
are complementary and which are different solutions to the same problem.
your best bet is bug tracker (which is becoming the sdm for
openacs4.x). The other three work but don't offer much functionality
and are mostly dead.
The more general question about new module vs. new version is harder
to answer and not always clear cut. A number of the packages that
have been mostly left behind were written while acs4.x was in flux and
have what have turned out to have quite a few bad design decisions and
the later reimplementations generally work better (this is the case
with forums, where bboard is just a little too ornate for it's own
good). Photo-Album and Photo-Album-Lite were written by different
people to meet different needs and such collisions are pretty much
inevitable and not something that it is that important to avoid (and
photo-album-lite has not been ported to postgresql so may get left
behind as well).
I think survey was close enough to simple-survey that it should have
been an upgrade not a new module but since I did not help do the work
I probably should withhold judgment. Forums is different enough from
bboard that I think it should be a different module, although a
bboard->forums migration script would be quite a polite thing for the
forum writers to have provided (hint).
It is unrealistic to think that the situation will be remedied any
time soon given the nature of how work gets done on OpenACS
(volunteers working on what interests them and contributions back
to the code base from paid client work neither of which are terribly
well coordinated). The dotLRN work seems to be a good counterexample
but even there my gut tells me a lot of the bug fixes and small
enhancements don't find their way back to the openacs.org code base.
I also think that in practice the idea that there are "module owners"
has obstructed getting improvements back in as well. No one deploys a
site with a single module and hence people usually have fixes and
enhancements across multiple modules. What I think happens a lot of
time is that these enhancements do not get submitted because whoever
made them thinks "well, I am not the module owner and I don't want to
step on any toes" or "I don't want to have to deal with the module
owner". I think we should actively try to foster a broader sense of
code ownership in the community and get people to funnel back their
work.
I have been trying to clear the backlog of patches and check/fix bugs
from SDM but it is discouraging that there are not more of both
showing up. I think if people running production sites would do a
diff versus the baseline they developed from they would find a bunch
of fixes that should come back to the code base, and ultimately
getting those fixes back in benefits everyone (not the least the
submitter who then faces a much easier task rolling to the new
version).
I have started to ramble here and will stop but I will say that
hopefully we can manage to pull our act together and write up what the
consensus is on which modules to use and which people should pick for
enhancement and have that be part of the 4.6 release notes.
A more modularized organization would also go a long way toward getting various out-of-the-box configurations set up (ie. install OpenACS core, then install [.LRN | .WRK | .STORE | .ETC]
