Re: [MiNT] keyboard.tbl / wiki addition / sparemint.org down?

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

On Tue, 2010-08-10 at 00:14 +1000, Paul Wratt wrote:
> On Mon, Aug 9, 2010 at 11:37 PM, Alan Hourihane <alanh@fairlite.co.uk> wrote:
> > On Mon, 2010-08-09 at 14:59 +0200, J. F. Lemaire wrote:
> >> On 9 August 2010 14:37, Alan Hourihane <alanh@fairlite.co.uk> wrote:
> >> > On Mon, 2010-08-09 at 14:29 +0200, Miro Kropacek wrote:
> >> >> > Speaking of missing files,  what happened to the "img" and "xobj"
> >> >> > subdirectories of xaaes? I can't find them in today's trunk.
> >> >> Exactly. And we wanted to make a release without RC :)
> >> >
> >> > And the daily builds have been running how long ?
> >> >
> >> > Just goes to show how little people use them.
> >>
> >> This is my perspective on the matter: I haven't been running the daily
> >> builds because the last time I tried I couldn't even get my Falcon to
> >> boot and I need it in a usable state and I don't have much time to
> >> spend on debugging the system. Now that a release is in the works, I
> >> gathered that things had settled in CVS and it was time for me to give
> >> them a try. And my Falcon boots just fine.
> >
> > That's one of the reasons for daily builds. Things get fixed fast. If
> > your Falcon didn't boot one day, it's a pretty severe fault and would
> > have undoubtably been fixed a day (or few) later.
> >
> > Bugs can creep in at any time, even in RC's. I think RC's work in larger
> > development communities to stop people committing huge new features.
> > Here we are a much much much smaller group of developers and I don't
> > think we bump into the same kinds of issues.
> >
> >> That, for me, is the difference between daily builds and RCs. The
> >> former can be quite unusable for different and very valid reasons
> >> while the latter are supposed to be at least stable. To me, there is
> >> something "official" about the RC state that says: "you can go for it,
> >> it should be fine".
> >
> > I can see people obviously like the "blessing of the code". I see things
> > differently being a developer, so I guess I need to be a little more
> > sensitive to the user base out there. But it's a two way street.
> >
> > Alan.
> >
> Then it would be in everyones interest (probably after this point
> release, see below) to look at a way to provide a reliable boot
> procedure for cvs builds, and (maybe) a script that automatically
> update the cvs build files
> 
> If the RELEASE procedure is followed (according to the code reference
> posted in another thread?) then this will be easy to maintain (stable
> in /mint/1-17-0, cvs in mint/1-17-cur)
> 
> Is there any problem with boot loaders choosing a different mint.prg
> (or running of these before mint is loaded). This is generally not an
> issue with ARAnyM but up till now I have only had a 1-16-cur and
> 1-17-cur version, not 1-17-0 and 1-17-cur versions.
> 
> Does anyone NOT use the version folder to boot and load mint, ie only
> out of /mint folder
> 
> The crux of this revolves around the folder checking order. Is this
> documented in the current docs?

These are not runtime checked, but build checked.

I've just marked the CVS with "BETA" status which means that the
directory search is...

c:\mint
c:\mint\1-17-0

It will not search the c:\mint\1-17-cur until I mark the codebase back
to CVS status, at which point we'll be tagging with 1-18-cur anyway.

Alan.