Now that we have 1.0.1 out the door, I'd like to draw up a roadmap for
our near future.

first, we'll need to have a stable branch for 1.0.x, which would include
bugfixes mainly. the main branch (the trunk) will be devoted to the 1.1
release. for this reason, I created a livesupport-1.0.x branch:

http://code.campware.org/projects/livesupport/browser/branches/livesupport-1.0.x/

we should all work on the trunk, with important bugfixes backported to
the 1.0.x branch.


for 1.1, I'd like to have the following from an organization standpoint:


- some directory structure re-arrangments

basically modules, products and tools would move into src/modules,
src/products, etc.


- real modularization of re-usable components

strangely enough, we don't have PHP products well, we do, but they
are all hidden in our modules directory. also, they depend on being
'beside each other', with lots of hard-coded references to each other.
this is strange, as we actually have a range of re-usable products, that
could be packages on their own:

- the localization component, with an HTML UI
- the storage server as it is
- the HTML UI for the storage server
- the authentication component (though this is more of a library)

I'd really like to see all these as 'products', which could be installed
separately. the main tasks of this being:

- remove hard-coded references to each other
- move separately installable parts to products from modules
- separate parts that make sense on their own (say localizer from HTML UI)


- having use-case descriptions for all feature requests

for all feature requests, I'd like to see use case descriptions before
evaluating them. this would clear up and detail the feature request as
well, cutting short the possibilities of misunderstandings. this would
also enable a more robust resource estimation for all feature requests.



for 1.0.x, besides obvious bugfixes, I'd like to have:

- packaging resolved for deb, ebuild and rpm-based distributions

this mainly involves getting proper dependency packaging (with our own
patches, if needed), and a re-thinking of our own configure / make /
make install cycle. I'll update our build environment document shortly
reflecting these changes.



Please reflect on the above, and also provide your whishlist for the
near future (from an organization / workprocess viewpoint)


Akos