santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Lautenbach <>
Subject Re: roadmap.
Date Thu, 20 Nov 2003 10:42:45 GMT
Erwin van der Koogh wrote:
> Peoples,
> A lot has been happening in the last week or two and I think it's time 
> to make a list of things we want to do and in what order we are going to 
> be doing them.
> Splitting the lists:
> With all the coordination required to set some of the other stuff up I 
> think it's best to split the lists in a security-dev and security-user 
> list. There's a +1 from me and Axl, I don't think you disagree Berin, 
> Karel?
> Any input from users?
> Setting up a new release:
> I think it's worthwhile to wait until the encryption stuff is in a 
> beta-able state, but what I don't want is to give the impression that 
> the signature stuff is in beta. So what would we do with the versioning?

I think we put together a release plan for 1.1.  We might start with an 
alpha, go to beta, go to final.

But we create a "release notes" file that clearly indicates what the 
changes are.  Specifically, minor updates and fixes to Signature code, 
but addition of XML Encryption code.

Does that sound reasonable?

> Setting up a branch for a Next Generation:
> Maybe it's best to set this up as a seperate directory?
> This way we can start from scratch and copy stuff over that we need 
> instead of having to cut out stuff that we don't need. I have been over 
> most of the code in the past few days and cutting out stuff is extremely 
> hard as none of us wrote it in the first place.

Well, if we fork the CVS, we can anything we want without impacting the 
old code.

So maybe this is an opportunity to create a "java" subdirectory for the 
java code?

It does mean we loose an easy linkage between code in v1 and v2.

At the same time, we have a very stable code base.  Working on it peace 
by peace to transfer it over to the JSR105 API would be good - it 
maximises stability.  The question is would it be better to work on it 
"in place" (so that at all times we have a complete working signature 
library with a mixed interface) or copy accross (so that we have only 
JSR105 code, but we start with a minimal library and grow).  Am not sure 
which is best, but I will sleep on it :>.

(Initial thought is the latter.  That we we know that before anyone 
checks anything in, they should be able to run unit-tests to get a full 
validation of any changes.)

> Formalizing the release process:
> With a dev list and a stable release I think we should be somewhat more 
> concerned about ad-hoc commits to the stable signature code. Maybe 
> require a precommit review by at least 1 other member? The encryption 
> stuff could be exempt from this and the new version is a free-for-all 
> for a little while.

I've been taking the attitude that I will tell the list exactly what I 
am doing either before I do it or immediately after.  Pre-commit reviews 
can get tricky, but at the same time I don't think there should be any 
surprises.  It's easy to revert a change in CVS as long as people are 
aware it has been made.

BTW - It would be fantastic if someone else could look at the C code as 
well, as I am a little uncomfortable being the only committer with no 
major reviews.

> Real releases will have to have a +1 from at least half of the 
> committers and no -1 from committers or users?
> After voting a mail with the results will be send to the PMC.


> How's that to get some stuff started?


> Regards,
> Erwin

View raw message