Re: [cc65] News for 2013

Hi Uz,

> I wish everybody on the list a happy new year!

Thank you, the same to you!

> A maintainer
> who doesn't maintain is worse for a project than no maintainer at all.

I personally would say that you're far from that right now - see this
lengthy message as example ;-)

> One of the things I perceive as wearisome is design and implementation of the
> library.

At least to me that doesn't come as a surprise. It was always clear
that you're more into solving problems than discussing problems...

> So I think, one of the first and most important things I should do is to cease
> control over the libraries.

Absolutely makes sense!

> This won't work completely, since for example the
> runtime and startup codes are tightly coupled to the compiler proper. But it
> will work for large parts.

From my perspective the runtime should for sure be considered part of
the compiler.

> Which means, the job of a library architect is open. Since I've also been the
> developer for the CBM libraries (C16, Plus4, C64, C128, CBM510&610 and PET),
> this place would also be vacant.

I'm happy that you consider these as two distinct roles as I think it
is very important to do so.

> Anybody willing to step in? Oliver, you have been responsible for most of the
> library changes in the last time. I have been really appreciating the great
> job you have done. Would you be willing to go a step further and take over as
> the principal architect?

I've intentionally been waiting for others to speak up before I
comment on this proposal. Given the sometime very lively discussions
on this list I'm sort of surprised that there was no feedback at all
regarding the actual proposal. To be honest I'm not sure what that
means. I assume however that it is save to preclude lack of interest
in cc65 in general (?)

Of course I really appreciate your positive feedback - and the trust
expressed in your offer!

Some thought from my side:

It's true that I pushed several topics in 2012. However in November
2012 I changed at work to a new position requiring much more time.
Right now on some days I'm even unable to catch up with my inbox
during the day. So I'll certainly be way less pushy than I was in 2012
- although some might consider this even beneficial ;-)

I understand that most cc65 users are only interested in "their"
target. Nevertheless I personally am very much into that cross-target
aspect of cc65. This aspect is mostly about the C library and
therefore I'm very much interested in the C library - a nice fit.

So for me the most important/interesting thing about the C library is
consistency across the targets. But that is something I certainly
can't drive on my own. I was desperate enough last year to implement
the device/directory stuff not only for the Apple2 but for the C64
too. But I do NOT plan to do this again as I was far from having fun
dealing with the peculiarities of CBM DOS. And even now the functions
in question are only available on just the targets I implemented them
for.

I understand that the following might turn off one or the other but
I'd like to be straight on this - my vision of the cc65 C library
development is a somewhat more structured one:

I see two classes of targets. The ones that are "actively maintained"
and the ones that are not. For the latter there are named
'contributors' while for "actively maintained" targets there's
additionally (at least) one named 'maintainer' for the target.

The overall goal is to create a harmonized, consistent feature set on
those "actively maintained" targets.

The maintainers commit to two tasks:

1. If a C library discussion is brought up and questions like 'pro or
contra' / 'left or right' are raised then they vote on that question
in a reasonable timeframe (something like a week).

2. If a decision for an enhancement/change was taken together and
there are no general reasons against it ("too" high implementation
effort, not reasonable - like i.e. lseek() on CBM) then they implement
that enhancement/change in a reasonable timeframe (something like
three months).

I guess that most readers on this list agree that the C64 is sort of
the reference target for cc65. I see a discrepancy between this
perception and the backlog items in
http://wiki.cc65.org/doku.php?id=cc65:reminders#cbm_library
and
http://wiki.cc65.org/doku.php?id=cc65:reminders#c64_library

So after all I'd say it's much more important to find maintainer(s)
for the CBM C libraries than that "prinzipal/general architect".

I'm personally willing to act as maintainer for the 'apple2',
'apple2enh' and 'geos-apple' targets. I'd really like to see at least
three "actively maintained" target families in order to create a
certain momentum: Apple2 and CBM and N/N. My current understanding is
that from the technical perspective the Atari would be a natural fit
as third target (family).

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.