[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

Paul