santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Lautenbach <be...@ozemail.com.au>
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.

+1.

> 
> How's that to get some stuff started?
> 

<GRIN>.


> Regards,
> 
> Erwin
> 


Mime
View raw message