IE> Leslie and Alex are both capable of making changes and improvements and IE> I'm happy to give checkin privs if they're interested (I think Leslie IE> has them already).
Yep, I'd like to get checkin privs too :) IE> Also, if someone wants to step up as maintainer I'm happy to step IE> down, but will hold the fort as best I can otherwise. I would consider a position of co-maintainer -- I'm not sure about a long run, but I could work more on Elephant for a year or so. To be clear I don't have a strategic vision at moment, but I'd like to focus on stability and usability improvements. The thing is we're going to switch to version 1.0 in stix.to (finally!) and so both I and Henrik are interested in getting Elephant stable, fast and usable. I'm also going to try BDB Elephant backed in my own personal small projects so it won't be left forgotten. Now regardless of whether I'm becoming a co-maintainer or not, what is our policy on changing things? Bugfixing and small improvements won't be a problem I guess, but if some API or major thing needs to be changed? Obviously it is a good idea to discuss it before implementing, but I'm not sure what counts as consensus etc. For example, I don't like that (setf slot-value) on association slots does add-association while slot-value returns a list of instances. This means that (setf (slot-value instance 'assoc) (slot-value instance 'assoc)) will signal an error because types are not compatible. I think this violates behaviour one expects from CLOS class. There is a similar API for set-valued slots, but in that case it works like an extension and doesn't break compatibility. _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel