Forum OpenACS Q&A: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1
Even bug reports get fun... is the report against the nsxml.so driver, or against my aolserver-nsxml binary RPM for a particular version of Red Hat, or againt my packaging of aolserver-nsxml binary RPMs in general, or against my aolserver SRPM which generates those binary RPMs... and some users may just report that "OpenACS4.x didn't install" against OpenACS4.x anyway!?
An admin interface that lets admins move a bug report from one product /package/module to another easily (and ideally tracks such moves as comments to the bug report or something) would be required.
Bugzilla isn't too bad at dealing with this, you can say that this bug report is against aolserver-nsxml version whatever, on Red Hat Linux 6.2. It's straightforward to query for all bugs against aolserver-nsxml on any platform, or just those on multiple RH versions, etc. and each user can name and store their own custom queries (using cookies). All the bug reports are in "one place" from a user perspective, and adding new products does not divide that up at all.
As far as I can see, SDM considers 'packages' to be totally distinct, and you (currently on openacs.org) only query within one package, so you can't ask for "all queries in all packages that have the word RPM somewhere in their subject line" or whatever. And there is only one subdivision (into modules) of a package. There's no explicit info on what hardware, or OS, or related subsystem(s) (Oracle or PG, and perhaps what version of each, will soon be vital info during OpenACS4.x testing, and if people are not specifically asked for that info, sometimes they will fail to provide it) the bug is being reported against.
If I used just a single SDM 'package' for all this stuff, and SDM 'modules', that works for bug reporting, but the download management stuff fails because the package has a single download link for a 'latest version'. Conversely, creating one SDM 'package' per binary RPM, or even one per RM per OS variant, allows download links to work well, but bugs will likely be reported across several packages in a way that might be hard to work with. And this would get people looking for the software not one 'place' to download the stuff from, but many links, they'd have to work out which subset of these packages they need for their particular setup. Until I split my own web page into two chunks, one for RH 6.2 and one for RH 7.1 (at the suggestion of someone who tried to use it!), some folks found doing that confusing even just within my page.
Stepping back a little, I think trying to build a combination bug-tracking system *and* a download manager as one unit may be hard to do well. If that is attempted, then I think the "download" link for a given 'package' needs to be able to ask questions of the downloading user (hardware, OS, database preference maybe, packaging preference maybe...) to guide them to the correct subset from among a potentially quite large group of files they should download. Links to some of those files may be "external" (ie not part of the ACS server concerned at all).
Hmm, if we did that, OpenACS 3.x RPM-related bugs could just be handled along with all other OpenACS 3.x bugs (maybe under an RPM 'module'), and there'd be no need for a separate download link from the software page just for RPMs. Requesting a download of OpenACS 3.x would offer you that as one choice among several, if RPMs exist for your particular hardware and OS combination. That would be nice!
But we don't have that right now... is it worth the work it would take to build?
Maybe the best option for now could be to set up just two packages (Aolserver RPMs and OpenACS RPMs), and have the 'download' link on /software for each of them point to a page something like my current whichfilesdoineed.html document, which could be on openacs.org too, say in file-storage or something, along with the RPMs themselves?
Pointers from one file-storage object to other such objects (the actual RPMs) seem sort of strange though ... easy to make mistakes with?
Are we seeking mainly to get the benefits of the bug tracking stuff from the SDM, or the benefits of its download management? Trying to get both from the current SDM for this collection of RPMs may be asking too much of it?
BTW, SDM seems to fit the OpenACS development setup much better than it fits my bunch of RPMs... it scratches the itch it was intended to scratch pretty well. Enhancing it to better handle RPM (or .deb, or even self-installing .exe for Windows users) packaged software sounds good to me... but if it would be a lot of work, or if doing so would make SDM less easy to use for OpenACS itself, that may not actually be the best way forward.
Final comment for tonight: getting OpenACS4 out the door, working well, and documented, is a lot more important than any of this 😊
