RE: [MiNT] What's in, what's out?

["Julian Reschke" <reschke@muenster.de>]

Hi,

I think we are now seeing some over-reactions. I still think that it was
worth having this discussion. At no point of time I was objecting to the
kernel being extended, or the direction to get closer to POSIX / Linux. My
main complaints that triggered my initial mail were:

a) SIGPWR added as "last" signal, although it's still not clear whether it
is needed and by whom.

b) /kern introduced without having an appropriate binary interface -- my
point was that it's better to add the "missing" functionality to /proc, and
then let /kern be a loadable module which just talks to /proc. Benefits: a
complete API on /proc, and /kern only takes up RAM for those people who want
it. BTW: in the past I remember that the "holy" goal used to be POSIX
compliance. /kern surely is not required for POSIX 1003.1 compliance, while
my ps utility that has been available for several years now surely is close
to it (POSIX 1003.2).

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Frank Naumann
> Sent: Tuesday, November 30, 1999 7:36 PM
> To: mint@fishpool.com
> Subject: Re: [MiNT] What's in, what's out?
>
>
> Hello everybody!
>
> > This is a list for developers, a forum whee they can discuss
> about things
> > related to the development.
>
> I never understand this list as a place for detailed kernel discussions.

Why not? It certainly used to be that back in the past...

> > But what's the use of a such a forum if some developers do all
> the important
> > discussion and decissions secretly by private mail?
>
> Because it's faster and more efficient?

That might be true, but the price seems to be that you're shutting out those
people whose opinion you don't want to hear.

> > OS>If anyone isn't happy with this situation, why don't those just
> > OS>include the stuff they want themselves
> > This means forking a new kernel tree.
> > Do have only a slight idea how much work and time it needs to
> maintain an own
> > kernel?
> > And do you really want to split the few developers into
> competitive projects?
>
> That's the point. Do you have any idea how much time it cost to discuss
> here about every small change?

Frank, I don't think that the changes that triggered this discussion can be
considered "small". Yes, it might be a small change of source code to define
the 32th signal, but it has a large impact because it de facto makes it
impossible to add any other new signal later (without a lot of work, that
is).

> So I ask all of you, that's the definition of this list? What's the
> strategy to discuss enhancements? How are conflicts solved? Is there
> something like a voting? Who is allowed to vote? Everybody? What with
> absent people?

I don't think that voting makes sense -- indeed everybody can fork his own
development tree if there's enough dissatisfaction. Discussing major changes
here however can help to reduce the risk. For instance I've heard several
things about those wonderful features that /kern will give us -- in fact,
many of them were already available in /proc, it just wasn't known (finding
processes that have a particular file open, finding the full process name,
printing the environment, printing the controlling TTY...). Discussing
things like this might help to avoid unneccessary new code.

> I never seen a statement about that and if I follow this discussion right
> it's time to define something like that.
>
> And in this discussion I also missed statements about the goal of
> FreeMiNT.
>
>
> For myself I don't like this discussion. I never thought that my work is
> so contentious. I don't have the time and I don't want to discuss every
> new feature or change here on the list. I do this in my spare time and it
> make lot of fun. But for this I need some freedom.
>
> Also Guido do it in his spare time and I think he do a great job. He tried
> to port the complete init suite. If we force him to rewrite it completly
> from scratch I'm sure he stop it because it's to much work. We don't have
> enough power to maintain our own system specific stuff.
>
> And yes, I make failures, nobody is perfect. But I make failures because
> I *do* something for FreeMiNT.

I don't argue with your authority to drive the development the way you want
it. However it seems to be that there could be a better balance between the
extremes ("discuss and vote any change" vs "just ignore the mailing list and
discuss things somewhere else).