Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc

[Ruddick Lawrence]

I am willing to help develop and maintain such a library (I was the original
poster, mrjogo, fyi), but I am more enthusiasm than experience, and
obviously it would need more developers. Are other people on this list
interested in helping with this (donating code, but more specifically the
longer-term commitment to maintaining it)? I think it could be a valuable
addition to avr-libc and the AVR community.

Ruddick

On Thu, Sep 17, 2009 at 1:25 AM, Joerg Wunsch <address@hidden> wrote:

> As Ruddick Lawrence wrote:
>
> > I guess the first thing to figure out is
> > how you (and the other developers/maintainers) define the scope of
> avr-libc,
> > and how best to design a complementary library (if at all) to house
> useful
> > code that is outside of that scope.
>
> Ideally, if there were enough volunteers to develop *and* maintain
> such a library (this includes maintaining documentation, handling bug
> and patch tracker submissions, rolling releases etc.), I could think
> of the avr-libc project being able to house it as a relatively
> standalone project.  It could get a separate top-level directory in
> the CVS tree, and roll separate releases from there.
>
> That way, users could decide whether they just need the low-level
> stuff from avr-libc, or want a higher level of abstraction, and install
> a second library on top of that.
>
> However, the biggest issue with that approach is finding enough people
> who are willing to actively work on that.  I don't see those who
> currently maintain avr-libc having enough vacant resources to manage
> such a project.  (That doesn't mean we were completely "out" of such a
> project, it's only we've got our hands full with maintaining the
> current state of avr-libc.)
>
> So, volunteers welcome. ;-)
>
> Lacking that, I agree with Eric that some fairly low-level interface
> abstractions might also go into the "classic" avr-libc, thereby
> extending its scope a bit.  However, if there were enough developers
> for a separate library, its scope could be much beyond the current
> avr-libc, so things like a generic HD44780 driver API could be there
> as well.  (Feel free to pick the current implementation from the
> stdioexample as a starting point.)
>
> I agree to the person in that thread about the GPL issue; in order to
> keep such a project under the roof of avr-libc, I'd say using the same
> licensing conditions as avr-libc is pretty much mandatory, as this has
> shown to cause the least trouble to every potential user so far.  This
> in turn would not allow re-using code of Pascal Stang's library, but
> of course, re-using ideas or APIs does not constitute a licensing
> issue.
>
> --
> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>