Re: [cc65] News for 2013

Hi,

> The approach you've described will mostly work, but
> from my experience, something is missing.

What I stated wasn't claiming to be sufficient - just necessary ;-)

> What about routines in the library that aren't part of any target library?
> Example: Stefan Haubenthal reported a bug in the printf family of functions.
> Who is going to fix that in your scenario? (Before anybody asks: It is unfixed
> until now).

From my (maybe limited) perspective work on the shared C library
wasn't the primary problem in the past because it could be done by any
single contributor without any specific target experience. Therefore I
didn't mention it in my already (too) long message.

> And what about the subsystems? Having three target library maintainers agree
> on something is good, but this is more or less coincidence if all three have
> just their systems in mind.

I imagined that this where the work of the 'library architect' starts...

> And then, you have picked the three most similar systems in your example
> above.

I know...

> Stefan Haubenthal has volunteered as a maintainer for the Atmos target,
> which is great!

Indeed :-)

> So the three maintained systems would be complete even without
> counting the Atari (which, by the way is maintained by Christian).

I absolutely intentionally didn't want to presume any of those!
Having provided most of the contributions for a target in the past
might be different from being the 'named maintainer' I was describing
in my message. And working with you might be different from working
with me. So everybody should express his will on his own!

> But the Atmos never had real mass storage devices as far as I know.

As the lack of mass storage for several targets was the main driver
behind my initiative to include statically linked drivers into the C
library it should be clear that I'm
- aware of this
- care about those targets

> Doesn't
> this break your concept of target maintainers working together to create
> momentum?

I don't see so - at least currently. If a certain target isn't
suitable for a certain topic like
- directory i/o when there's no mass storage
- tgi stuff when there's only text video
- sound stuff when there's no sound chip
- ...
them the maintainer of that target is supposed to say so - and then
he's just out of the game for that topic.

The "interesting" scenario is when a target is generally considered
applicable to a certain topic but the maintainer states otherwise as
he's not interested (enough) for a discussion/implementation.

I'd say it's a question of the quality of the work of the 'library
architect' how such a situation is handled.

> Similar thing is the Lynx (maintained by Karri): It is a console,
> which has slightly other requirements than a home computer system like the
> Apple ][.

Again I'm pretty aware of that. I did i.e. several hours of research
just to make sure that the aspect ratio I added to its tgi driver is
indeed exactly 1.

> Having the Apple, CBM and Atari maintainers agree on something might create a
> bad solution for the Atmos or the Lynx (or other systems).

But those decisions have been made in the past many times. What i.e.
about the intrinsic overhead of loadable drivers for targets without
mass storage? Or their overhead for targets with exactly one
mouse/joystick/graphics mode/serial interface?

> So I do really
> think that it would be advantageous to have someone who cares about the
> library as such, speaks up for not very well maintained systems or thinks
> about general concepts without regard to a specific target.

Hm, I get more and more the notion that there's a misunderstanding. I
was under the impression that the 'library architect' from your OP is
that very person you're describing here. I don't want to remove it
from the picture - especially after it sort of looks/looked like I
might be it ;-)


I didn't want to say that the active maintainers decide alone. I
wanted to say that they play part in the decision process - simply
because it just doen't make sense to me to ask somebody to commit
himself to implement something he didn't have chance to be part of the
decision.

Or to put it in other words: Whoever commits to implement for a
certain target gets in turn the guarantee to take part in the decision
process.

I think the past there were sometimes way more voices in discussions
than hands actually willing to work on the result of the discussion.
That sometimes demotivated contributors and I consider it therefore
contraprodictive.

That doesn't mean that discussions are supposed to happen behind
closed doors. It's supposed to mean that - to put in very plain words
- the ones doing the work should be the ones deciding. Simply because
in open-source that setup usually motivates - and is just more fun.

> But anyway, thanks for your feedback. I will need to think about possible solutions.

Yeah, ceasing control doesn't necessarily feel good ;-))

And again - I intentionally let several days pass by before entering
this thread. And still - if there's somebody "out there" interested in
the 'library architect' role (and feeling to have potentially less
misunderstandings with Uz) please speak up!

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