Forum OpenACS Development: Re: Who maintains photo-album, package owners in general

Collapse
Posted by Vinod Kurup on
I integrated Michael's and my changes into CVS. It's currently in contrib on the HEAD. This includes porting Jeff's changes to Oracle, upgrade scripts for PG and Oracle, and working drop scripts. I bumped the version number to 4.5.

This version requires ImageMagick and jhead to be installed on your system.

Okay, so we have photo-album, photo-album-lite, Jeff's version, and Vinod's version.  What would it take in terms of testing and development to get the best code (apparently Vinod's compilation of peoples' work) back in as the core photo-album module?  Or is that what you already did?

What is jhead used for?  Looking at the docs, it's for digital camera images.  If you don't use a digital camera, can you use the new photo-album without installing jhead?

Collapse
Posted by Jeff Davis on
photo-album-lite and photo-album should both just go away and the contrib photo album should be the only version (and I guess it should go back in to packages although I sort of like things which are not really critical packages to be in contrib and more clearly independent modules rather than part of openacs proper -- it's a small step in the direction of non monolithic releases).

jhead pulls out the exif data and photo-album as written won't work without it. It's also used to remove the embeded thumbnail from the thumbnailed image, some cameras (and I imagine things like photoshop) produce embeded thumbnails which can be quite large and when imagemagick scales the image for a thumbnail it does not remove the embeded thumbnail which means the image file can be 40k rather than 8k. Anyway, it's public domain and pretty easy to install so I am disinclined to change anything so it works without it. If someone else wants to that's fine I guess.

Vinod applied the patches to the version in contrib/packages so there are not two versions floating around.

I have a bunch of small fixes to photo-album that I would like to check into /contrib/packages/photo-album on the HEAD.  Here's the summary:

* tcl/photo-album-procs.tcl:
    - in pa_context_bar_list, instead of returning nothing when we are in the root folder, should return [list $final].  Otherwise, you get an incomplete context bar in the root folder.

* www/clipboards.adp
* www/clipboard-delete.tcl (NEW)
    - changes to allow users to delete a photo clipboard (capability exists in SQL API but never exposed in UI)

* www/photo-move-oracle.xql
* www/photo-move-postgresql.xql
* www/photo-move.tcl
    - change to allow users to move photos into any album below the root folder where they have appropriate permissions (to be more consistent with album-move)

* context bar fix to 16 ADP files
    - The context bar is being passed to the master template as "context_list".  Changed to "context" so that it works with the current default-master.tcl and is more consistent with other packages.

Can I have permission to check these changes in?  Or, if you prefer, I can email a tarball of the affected files.  If so, who should I send them to?

Thanks...

Collapse
Posted by Jeff Davis on
Robert, I gave you commit on contrib/packages/photo-album.
Feel free to commit your changes.
You rock!  Ok, I checked the files in.

Could you do me a favor and quickly eyeball my change in www/photo-move-oracle.xql?  I think it's correct, but I don't have an Oracle installation to test against.

Also, who/when can we move photo-album into packages from contrib?

Thanks...

Collapse
Posted by Tilmann Singer on
The original package list from Janine Sisk is still online:

https://openacs.org/projects/openacs/developers/package-owners

Peter, didn't you want to remove this? Is 'Package Inventory' (at https://openacs.org/projects/openacs/5.0/package_inventory) now the recommended way to find out who maintains what?

Collapse
Posted by Carl Robert Blesius on
Why not just generate a package inventory list for the maintainer page from the data in bug tracker and the APM?

Advantages:
1. We add a new "component maintainer" using the bug tracker admin interface we automatically update the page and this person is automatically assigned new bugs for that package.
2. If we want the page's description of package functionality improved we add it to the text in the APM and the description for administrators in the APM is improved.
3. Most importantly: nobody has to mess with that page again.

Hack so we do not loose any info that is on the page now:
We add quality/test status as well as major todo's/plans to the description in the bug tracker (not sure if this is needed though... might be better to just link to a filtered list of high priority and/or critical bugs for that package).