Massimiliano Pala wrote:
Michael Bell wrote:
1. ScheduleOk. My proposal is to fix the small things - having the snap usable in
-----------
There is no exact schedule. We start the discussion now. So who should know when we finished :)
every part - and then starting the snapshots and RCs. If we start fixing
the code I guess we can have the release ready for november.
I think this is really optimistic because OpenCA includes now much more subsystems then in 0.9.1 but optimistic schedules are better than no schedules :)
2. Stability ------------
Here the documentation is really important and should be CLEAR where to put hands to configure the files. I think it needs some work about what options are available for channels/login and default values.
Ok, this is no problem but parts of these files are already documented.
About this I noticed the AC module does not accept "empty" parameters when configuring channels for pki or RAs so, after a brand new installation it complains almost about every parameter in the default configuration files. We have two options: changing the default values to be suitable for a "normal" apache installation or changing the AC module so it can accept ".*" values without complaining about them.
The AC module accepts already ".*" values because it supports regular expressions when text is expected. I never changed the access control configuration by hand on my notebook. If you want to run a real PKI then you have only to change the network entry.
4. Distros
----------
Distributions are the next big problem. Should OpenCA publish packages?
My answer is: yes. The problem is that this requires time, is there anybody who wishes to help in this ?
There are many Linux based distributions, BSD styles and commercial
[...]
outdated. I think it is better to have no RPMs than to have outdated RPMS for only a small number of Linux distributions.
As I said before I think we should keep updated rpms for a very small number of systems. Actually I guess it could be useful to have packages for RedHat at least, SuSe is the next on the list. Other systems can use the provided RPMS with very small changes... BSD and Solaris are the next on the list, but I guess someone else should take the task, not us.
Ok, do you have an idea how extract all the specs from the src tree and put it into a central directory? I would like a strcture like this:
contrib/packages/redhat/ contrib/packages/suse/
These directories should include all the distribution specific stuff because there is no good reason why we should install on Solaris or Debian a source tree which includes specs from RPM-based Linux distribution. Debian for example has a a file which will be applied as patch to a tar-file of the source.
I want to have a src-area without distribution specific stuff. The distribution specific stuff should be in one directory. This is much easier to maintain for the packers and we have no spec-directory in every module. Also every distribution can decide by itself how to distribute OpenCA (as one big package or several small packages or whatever).
I stopped updating the SuSE packages because it costs to much time to maintain the specs. If the specs are centralized in one directory then this would be much easier. What do you think about this centralization to ease the maintenance and cleanup the source?
5. Documentation ----------------
I think we could enable the installation of an online reference so that the HTML version is accessible from within the web interfaces. At least from the CA.
This is no problem. Only the installation must be tested for dynamic content.
P.S. before somebody asks; I try to integrate OpenSC smartcards as HSM but actually I have trouble with their PKCS#11 module. If we ever get OpenSC or MuscleCard working then we will add it to 0.9.2.
I know it could be really useful, but I would integrate it into 0.9.3. The problem with this release is that we added too much code and we are still integrating new features.
We should stop adding and start fixing now, so we can come up with a new release, I guess, in a couple of months (I want it to be stable, and the new code is far from it).
We can add support for OpenSC at every time we want. We can add to 0.9.2 even after the official release of 0.9.2! The reason is very simple. A new token effects no other token module after we organized the integration of hardware like DBI the integration of DBDs. You can only get a problem if you try to load this token. So it is not necessary to discuss about OpenSC :)
Best regards
Michael -- ------------------------------------------------------------------- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und Medienservice Tel.: +49 (0)30-2093 2482 (Computing Centre) Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
