Re: [MiNT] trunk-09082010 file structure / content

[Alan Hourihane <alanh@fairlite.co.uk>]

On Mon, 2010-08-09 at 21:15 +0200, Miro Kropacek wrote:
> Hi,
> 
> before making any tests I'd like to propose a few changes to current
> build (which we call now RC, right Alan? ;-)
> 
> - deactivate all kernels by default (i.e. making them .PRX or
> whatever), user can depack archive and reboot, without reading
> anything, he will see some error about bad CPU and he might not be so
> motivated to investigate why it happened

I'll default to 68000 and PRX the others.

> - use only kernels from 1.16.1 -- 000, 030, 040, Milan and Aranym.
> There's no point of using 117 (020-60 = 020+ FPU, no difference to 030
> as kernel doesn't use FPU) coldfire (who uses it?) or even debug
> kernel. Who wants a debug version, he need to be motivated to
> contribute somehow and we all agree it's best to use (future) trunk
> debug build then instead of some release debug build. 040 is
> essentially equals to 060, at least right now, it will start to differ
> when Motorola's sources will be included and used in CT60 kernel (for
> FPU / unimplemented instructions emulation).

060 is compiled with m68060 and 040 is compiled with m68040 and the file
sizes differ so I'd expect the 060 version to be using 68060 only
instructions. As for debug, I can remove. Some people do use coldfire
now :-)

> - same for XaAES builds, 'ozk' and 'debug' shouldn't be there, a fact
> 'xaaes.km' is build for 030 isn't emphasized anywhere, 040/060 -->
> same ones, we don't need both of them

I'll remove ozk and debug. The other comments should be fixed by Helmut.

> - don't include all CVS documentation, at least until some cleanup is
> done. Basically, it's just random collection without (nearly) any
> structure in various stages of completeness. I'd vote for including
> user manuals / readmes / config skeletons for mint, xaaes and kernel
> modules, nothing more. Developer docs can be restructured later, I
> don't believe there's a person who ignores CVS / source tree and needs
> those docs.

To be honest, I'd prefer to ship a very sparse piece of documentation
and point people to a wiki. That way it's easier to be dynamic in
updating documentation. 

Any disagree to me removing the entire doc directory from the tarball
and including something very thin ?

> - mimic and extend "driver" folder from 1-16-1, i.e. not only include
> 3rd party modules (assemsoft, ct60 (!) ethernec, ... ideas welcomed)
> but also xdd and xfs to amplify a fact these are equal to use (i.e.
> copy to mint folder when desired) and sort them by some key (target
> machine perhaps?)

I don't like shipping 3rd party modules as I'd like people to know where
they get the code. So if they wanted the Assemsoft binary EtherNEC
driver they should go to Assemsoft to get it. If it's code in the CVS,
then no problem.

> - extend "tools" folder, I know in 1-16-1 aren't all included but I
> think we should fix a build where possible and include all possible
> tools (I fixed some of them, if there's still time / interest, I can
> contribute with a patch) OR to fix them and release them, along with
> freemint, as RPMs

tools should not be in the kernel build, they should get moved to
mint-util or something.

> I could do all of this dirty work but question is how to contribute?

Patches would be good, even to documentation. Get all the doc directory
onto the wiki so we ship very little docs would be magnificent.

> It's mainly about copying something to something, renaming, deleting,
> shorting a filename to 8+3, ... I see only 1.17 readme is in CVS. Is
> it ok to "repackage" current trunk following scheme above and post a
> link here? What do you think? I'd fix also some doc bits.

Currently the tarball is created with a manual script, it'd be nicer to
get a "make install" working with the FreeMiNT sources so that make
install does all the hard work for us. If you feel like doing that, you
could essentially take all of your comments above and work that into the
CVS. That'd be great.

Alan.