I'm game if Ron and Frédéric are willing. I have extensively used the simpler aspects of SVN (ie, no branching or merging), and I hear CVS is similar enough.
I agree we should move further discussion to a dedicated list in order to stop bugging people here who are uninterested. As for the name, do we want to tie it to avr-libc in any way (but not as confusingly as Procyon AVRlib did...)? Something along the lines of avr-libc-extension. Or it can be completely whimsical, such as avr-packmule (it does the heavy lifting). Ruddick On Thu, Sep 17, 2009 at 12:35 PM, Joerg Wunsch <j...@uriah.heep.sax.de> wrote: > As Ron Kreymborg wrote: > > > I now have a little more spare time, so would be willing to join as > > a volunteer for this library. > > > As Frédéric Nadeau wrote: > > > I started such a project at the beginning of the year. Please check > > at: http://code.google.com/p/avr-drv/ > > > [...] I'm > > willing to work on that and would see no objection to actully give > > that code to the AVR-LIBC project. > > > As Ruddick Lawrence wrote: > > > I am willing to help develop and maintain such a library [...] > > > Cool! That makes three of you, I think that's enough for a start. > > > How to proceed from here? Do you all have CVS experience? I think > the next step would be to discuss an API. I think it might make sense > to setup a different developers list so things like that API > discussion could be done there. Oh, that also asks for a name for the > new library then ;-), as that name should probably be reflected in the > name of the mailing list. > > What do you thkin about it? > > > As Ruddick Lawrence wrote: > > > ..., but I am more enthusiasm than experience, and > > obviously it would need more developers. > > I'm willing to act as a consultant for technical details, like > organization of the CVS tree, and I could get you going on how to roll > a release. If you are willing to establish an autoconf/automake > infrastructure, you could basically re-use the release preparation > instructions from avr-libc (which are described in detail in the > documentation). > > > As Ron Kreymborg wrote: > > > I guess it would be a library of modules with a documented API for > > each. The trick would be to ensure any common code in modules from > > various contributors is extracted out into the one place. Otherwise > > including more than one module could mean possible code duplication. > > Well, that certainly needs to be discussed. But don't worry too much, > a consistent and relatively stable API is more important than details > like how to avoid code duplication. Then, as long as you stay with > the API once agreed to, anything else will be details internal to the > library, which could be easily changed between releases. > > -- > cheers, J"org .-.-. --... ...-- -.. . DL8DTL > > http://www.sax.de/~joerg/ <http://www.sax.de/%7Ejoerg/> > NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > > > _______________________________________________ > AVR-libc-dev mailing list > AVR-libc-dev@nongnu.org > http://lists.nongnu.org/mailman/listinfo/avr-libc-dev > _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
