|Subject:||Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc|
|Date:||Fri, 18 Sep 2009 09:20:18 +0200|
|User-agent:||Thunderbird 220.127.116.11 (Windows/20090605)|
Joerg Wunsch 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.
Can I add a few comments here? First I'd like to applaud the volunteers here - enthusiasm is more important than experience for a project like this, and I think it is great that you are able and willing to spend time on this library project. The world of embedded development has too many people like me - lots of experience, but little time to spread it around since we work too much!
One thing I'd like to suggest is that the "library" be divided into separate areas. In particular, I'd like to see a "stable" area and a "staging" or "experimental" area. A module will only be moved into the stable area after it has been well tested on a variety of devices, documented, and after the maintainers and the mailing list have generally agreed that it is ready. These will be modules that users can rely on, and which the library maintainers are committed to maintaining over time.
The "staging" area would be for modules that are proposals. They should be good enough for people to make use of if they want, but there are no guarantees about stability of the code or the APIs. This gives you an area for code that you'd like to see tested by others, without the risk of being stuck with a sub-optimal API or implementation.
There may also be a "what you see is all you get" area, where you can keep code that is donated but not documented, maintained, tested, or otherwise ready for the main library. This would provide a cheap entry point for people who could provide code, and users can take it or leave it. If the code looks generally useful, it could then provide a starting point for a full library module. This should of course not just be a dumping ground for any old code.
What I'm aiming at here is a way to get more code into the project, and to allow different levels of completion (including documentation, generalisation, testing, ABI stability, code style, and commitment to maintenance) for different modules. Modules of common use to beginners must have a higher standard and ease of use than unusual modules useful only to a few. And it is very important that these distinctions are made clearly, so that users know what they are getting.
Joerg has suggested using avr-libc's system for building and infrastructure, which would be a good starting point. However, I think you should be open to other ways to use the code than as a traditional static library build combined with header files.
For some modules and uses, it could be more practical for users to simply add the module's C and header files to their project. There are several advantages to this - debugging is easier, code optimisation is better (it will compiled with the same flags as the rest of the project, possibly including --combine and -fwhole-program), it is easier to keep the code stable (especially if the module is not from the "stable" area), and it is easier to modify the code.
Making the modules re-usable in this way might mean more effort is needed in making the modules stand-alone, or at least with clearly specified interdependencies. This is perhaps a good thing in general, as modules will typically be written by different people. Another issue is licensing, although I think the avr-libc license allows such use even with modifications to the library modules.
You might also want to have areas set up as a wiki for information, and perhaps areas for sample code (either full demo programs or code snippets). But that would perhaps be stretching the scope of the project too far.
On a practical point, having a separate mailing list is a good idea, but with announcements copied to the related lists (like this one). It would also be nice to have the list registered at gmane.org - I find gmane.org very convenient for many of the lists I follow.
|[Prev in Thread]||Current Thread||[Next in Thread]|