FYI - I still run three production sites on Elephant BDB, although I haven't been tracking Oracle's latest releases... I'll upgrade at least one of them to the next version you release and do some testing.
Elephant has been in pre-release status for a 1.0 release for almost three years now, it would be fantastic to clean up the remaining API, testing, and stability issues. That would be a great co-maintainer contribution. I was also unhappy with the association slot API so don't use them myself and there are other awkward issues here and there that kept me from declaring a 1.0 release. As far as process is concerned; just run architecture or API change proposals by the list before you make them. I used to consider silence as assent. I will chime in as I can on likely consequences of changes or render an opinion, but feel free to use your own judgement. I would recommend a complete code review of the schema implementation as a good first step; that's one area that often causes problems when making changes to different slot types. I'm sure you'll catch design or implementation issues that I missed at the time. Thanks, Ian On May 1, 2011, at 12:08 PM, Alex Mizrahi wrote: > 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 _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
