Re: [AD] Organizing an Allegro Hack Day

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


In case I'm otherwise occupied atthe time of the meeting, here are some of 
the main things I have to say.

* 4.2 branch (only bug fixes allowed?)
My position is yes, only bug fixes allowed. For a variety of reasons: 
testing of new functionality, possibility of introducing new bugs, 
backward compatibility in the compatibility layer of 4.3, time taken away 
from 4.3 development. For some things (resizable windows, multiple 
windows) patches/hacks existed during the 4.1 series and they were 
rejected (either by consensus or by lack of genuine discussion) on the 
ground that it would be better to do a more proper implementation of them 
when overhauling the graphics drivers anyway. If we had wanted to 
implement things liek this in 4.2, then that would have been the proper 
time to do it. Let's be honest: if 4.3 were not a major overhaul, then 
this wouldn't even be a topic for debate.
I do see how there is a problem that 4.3 as is is not directly usable. The 
way around that, in my opinion, is to make sure that the 4.2 compatibility 
layer is at all times functioning. That way, people can actually use 4.3 
normally (good for testing) and experiment with new functionality if they 
want (having been warned that the implementation is in a state of flux and 
liable to change).

* OS X
Not sure what there is to discuss on this front. I know Thomas Harte is 
vocal about Allegro mostly treating OS X as a generic UNIX system, which 
it is not. I think he's right to do so and we should invest in making it 
more OS X "native", but this could be tricky to organise. Getting a census 
on who uses OS X might be useful.
I have an iBook G4, which I mostly don't use for Allegro-related stuff.
On a similar vein:

* Windows
This keeps popping up, and it's been discussed many times. There are some 
standing issues (see the mostrecent threads on the dev forum on ACC) that 
need resolution and developer intervention.
I personally do have Windows installed, but no developer tools - and quite 
frankly, I don't have the time to look into Windows issues unless it's as 
simple as compile&run.

* Display & Graphics (bitmap manipulation)
I think my position here is clear. :)
To me, a "display" is something like an application window, a "bitmap" is a 
distinct object that might or might not be attached to a display. For a 
display, things like buffering and vsyncing make sense, for a bitmap as a 
seperate entity I think not. My experience with state based machines is 
that they tend to make things more complicated in the long run. This is 
not the case when dealing with single instances of a particluar type of 
object, but when dealing with, say, different displays or off-screen 
bitmap manipulation, I find them confusing and bug-attracting. I realise 
that is a personal preference, and it may make an OpenGL implementation a 
bit more awkward to implement (though it seems to me that should be fairly 
easy to work around and should only affect internal anyway).

Other:

* Dictatorship/leadership and releases
I've brought this up before. I think the current system depends too much on 
wether the Dictator has time to invest (or at least it seems that way to 
me), which none of us seem to have in abundance. One of the things I 
proposed earlier is to appoint Dictators for each branch instead of for 
the project as a whole (in which case, following Roman nomenclature, the 
term "consul" might be more appropriate). Another possibility is to 
appoint a Dictator for a limited time only and then replace him (or, 
technically, her). If someone reads into this that I'm very busy and the 
time I have to spend on Allegro is limited, then that someone reads 
correctly. I'm fine continuing to do releases for 4.2 and making 
announcements, but I certainly can't promise more than that.

I think these are the main things I would want to bring to the discussion 
and my position on them. I'll try to pop in on the IRC channel (provided I 
even have an IRC client installed, I might not), but I may be a little bit 
late. Discussion on input/events and the sound API I gladly leave to 
people more knowledgeable on those.

Cheers,

Evert




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/