I think the first step is building the latest development copy of Allegro from version control. You can't begin to contribute if you can't build it. Any trouble you have building it should be noted so that you can help to improve the documentation or build system to make things easier for your given platform for the next guy.

From there run all tests/examples. If any of them don't work then you have an implied task for asking about the status of them on the developer mailing list (searching the archives first would be ideal) and whether anybody is aware that said examples or tests are broken and/or are working on fixing them. If not you can work on either fixing Allegro or fixing the example/test.

You can then move on to other things. Try to write your own program using Allegro. That is really the best way to contribute. If you aren't using Allegro you will find it hard to be motivated to work on Allegro, let alone understand what needs to be done. By writing your own programs you are likely to run into limitations or bugs in either the documentation or software. Repeat mailing list communication and potential contributions.

Everybody always says "I would like to help out" because we all want to do so. Actually doing it is a lot more difficult and doesn't start with a mailing list or forum post. I believe that is what Trent was trying to say with this:

(Emphasis mine)

It's great if you want to help. Get started now. Posting on the forums or even the mailing list that "I will help out, tell me how!" isn't really useful. The developers probably don't have the time or motivation to hold your hand to that degree. At least not until you really prove to them that you're serious. You will need to motivate yourself somehow and just dig in. Find yourself some spare time and get to work now. Make some progress to show that you're serious and you will be more likely to get guidance to steer you in the right direction.

For the most part, from what I have gathered on IRC, the developers are individuals with their own individual goals, that coordinate via the mailing list to avoid stepping on toes or wasting time doing something unwanted or redundantly. You will generally have to come up with your own specific tasks. The other developers will be useful in helping you to identify how practical or useful that work will be to the project, and maybe helping to narrow down your search for where to begin. The easiest contributions to get adopted will be documentation. Getting familiar enough with the source code to help in bigger ways may take weeks or months of trying. But mostly it will be about building it, identifying a bug that needs fixing (either by existing reports or by your own trial and error), and then doing your best to figure out why it happens. Standard debugging procedures exist, except I imagine the bugs are mostly related to graphics processing intricacies or windowing systems integration and interfacing. In other words, a brainfuck of standards and substandards colliding.

I have to admit, all this talk about 5.2 is pretty exciting.

Personally, I would prefer a 5.2 over any further additions to the 5.0 branch. It has always been hard back-porting things (even simple bug fixes) from 5.1 to 5.0, and it's not getting any easier. I think stabilizing some (definitely not all) of the 5.1 API in the form of a 5.2 is a lot more useful than porting this API (which is very hard) to 5.0.

I built the current git HEAD on OSX 10.10 - no errors but a lot of deprecation warnings. I can see if I can do anything on these, unless someone else is already on the case?

Looking a Peter's list, is it fair to say that none of these are new features, just clean ups/bug fixes/missing implementations? IOW is the code now at beta stage?

Pete

@Peter Hull

I think according to Peter Wang's list there are also a few API in git that may need to be checked if they are usable or not. And which may need an overhaul if they turn out unwieldy.

a general software development question (not limited to Allegro in particular)
Is it always necessary or even desirable to shoehorn software components or subsets of functionality onto platforms or hardware components in a way which goes fundamentally against the nature of those platforms?

and what does that have to do with Allegro?:
If a platform does not have a mouse then that platform does not need to have an emulated mouse either or a mouse example because software designed, written and meant to be used with a mouse would always be unnatural and probably hard to use without a mouse.

The mouse functions on that platform should then simply do nothing and any mouse examples do not apply to platforms without mice.

Sure, it would be convenient to have a minimum layer of mouse emulation which translates touch screen input to clicks somehow and would allow largely the same unmodified code to be re-used on platforms of different nature but it is against the nature of a touchscreen to do that and the right way to do this kind of thing would be to abstract both mouse and touchscreen input into an extra compatibility layer and giving it an entirely new name, like "pointing device input" which would pull data from mice and touchscreens and present it on the programming interface in a new unified way which grants access to all input data from any of those pointing devices.

The mouse interface and touchscreen interface would still be there but they would each be their own platform specific interface and if one were to write platform independent code without caring about which devices generated a certain input event, they'd use the unified new interface and do not need to worry about using either platforms interface or emulating one on the other.

And what if a platform has mice, tablets and touchscreens? It would make the most sense to have a separate interface for each for functions which are mutually exclusive/unnatural between these components (e.g. tablets and touchscreens can have pressure sensitivity while mice usually don't) and at the same time have a unifying extra interface for shared behaviour like determining whether a "click/tap/touch" happened anywhere and where it happened.

I am not actually helping with this though as it would add a ton of additional work to implement these things and I am not ready to do it myself.

I checked out a working copy from git yesterday but haven't yet familiarized myself with Arch Linux (or any of the available editors on it) sufficiently to do any development on it and I guess that's also irrelevant for Android development too (the only phone I have still runs on Android 1.6 I think and there were never any upgrades) and I guess the Linux version is not the one which requires any/much work to be done.

I see. I think things like that should be hidden in the platform specific initialization code then, so that they are done for example inside that platforms implementation of the "al_install_mouse" function so they would not clutter up any example/user code.

Likewise, the function which takes the tests for the escape key should be modified to internally test for that back thing then (but only on that platform) even if escape is passed in as the parameter.

Maybe I am only stating obvious things here though which have already been discussed and agreed upon earlier so I will stfu since I do not know the internal structure of the Allegro code to judge how hard it would be to add these things (these two examples do not sound like they should take more than a couple of lines of code).

It's not a matter of that. That would be easy to do but it would be incorrect. I'll shut up now and take this to the mailing list.

5.2 has been planned since at latest March 2013, as the post I quoted by Peter points out.

It doesn't really matter. The project members can decide to change that. I think that releasing early and often might be a better development model anyway. Nevermind "stable" releases. Just start releasing and get those that use Allegro for real work to start using these bleeding-edge releases. They'll find bugs faster that way and hopefully it will keep the entire ecosystem alive and thriving. Having developers go off into the dark to develop for 5 years doesn't really stimulate the community, nor the developers.

I don't think that calling it 5.2 is necessary though. I see no reason to bother actually making a "stable" release of Allegro 5 again until work is pretty much finished and there are no more todos considered worth being integrated. From then on the only changes needed are bug fixes and vulnerability patches, or if new features arise in the future begin a new unstable release to work on that.

Whenever there is an unstable release post a warning about any API or ABI changes that will affect users with a simple mapping of old and new that users can use to update their code with ease (and if nothing is needed all the better). I see no need for such a formal, long, drawn out process for a small, struggling community. It would benefit the community to probably follow the development more closely. And might make it easier for those with an interest to get involved in the development and help to stimulate the community.

There's also the unfortunate problem that a lot of people misunderstands the "unstable" attribute of 5.1 releases, which has (next to) nothing to do with program stability...

The "5.2 Roadmap" on the Wiki isn't official, I've never even seen it. Obviously not written by developers.

Not saying it's not stuff that's planned, just not for 5.2.