Difference between revisions of "Liblicense 04 release todo"
m |
m |
||
Line 5: | Line 5: | ||
** OLPC integration | ** OLPC integration | ||
*** Journal integration | *** Journal integration | ||
− | ** i18n | + | ** GUI i18n (liblicense core already handled) |
* bugs/issues | * bugs/issues |
Revision as of 18:22, 31 July 2007
- features
- KDE4 integration
- system settings module
- file properties license tab
- OLPC integration
- Journal integration
- GUI i18n (liblicense core already handled)
- KDE4 integration
- bugs/issues
- License chooser api ironing out (http://lists.ibiblio.org/pipermail/cc-devel/2007-July/000539.html). I could wrap the flags to hide the bit-shifting -- but before I do that, I want feedback as to whether this design, in general, works.
- Use SONAME so applications can request a particular version of liblicense's API/ABI
- Debian will require this (and everyone else is crazy if they don't)
- I found one explanation of it while Googling
- not clear what default-content-license does, exactly- maybe replace 'Default Content License' with 'choose the default license for new content you create' or something like that? (whatever is accurate :)
- I'd get rid of the frame around the license chooser. Not used by most gnome apps.
- URI: what goes there? I assume the license URI, but I'd expect the license chooser would set that, and it doesn't appear to.
- are there sample files somewhere I can test the nautilus extension on?
- good packaging practice would break this into liblicense and liblicense-devel, one with the apps and app data another with the libraries. Not a huge deal, but would be necessary before getting it into fedora, for example.
- tag svn
- package
- source
- rpm
- deb
- ebuilds (bugs 187196, 185689, and 78021 in gentoo's bugzilla)
- test them!
- Known dependencies.
- libraptor
- nautilus-python
- exempi
- publicity
- freshmeat
- sourceforge
- ?