Stable: 2.5.2
Development: 2.6-alpha3
Yes, folks, MOC is ten years old today. Well, it's the tenth anniversary of the first commit into SVN anyway, but the first official release of MOC which I can find predates that by some two years.
With MOC 2.5.0 finally having been released and MOC 2.6 now underway, it seems like a good time to take a look back at where we've been and a look forwards to let people know how I see MOC development unfolding from here.
MOC 2.5.0 "Consolidation" was a very long time in the making. It was a transitional release and drew a line in the sand between Damian's development of MOC and my own maintainership of it.
For some time prior to my taking up the role of MOC Maintainer, Damian had not been able to devote the time required to keep MOC moving forward. He had new work and family commitments, and MOC had become a lesser part of his life. So MOC was beginning to suffer through lack of maintainance.
My involvement with MOC began late in 2008. I wanted to use MOC to do console-based rough audio editting. That involved some work in MOC to provide the mechanisms I needed to support that primary functionality. It was completed and I have been using it for over five years now. But it still hasn't made it into the MOC codebase because if it is to be released publicly there is more work required to generalise it and provide a seemless and consistant interface. I'm still working towards that goal.
Damian asked me if I wanted to take over the maintainance of MOC. I was reluctant to do so because of being unable to meet the time commitment involved. However, over the next few months I ended up falling into the role anyway as I got further and further into integrating my new functionality and became more and more familiar with the codebase.
I soon realised that my work could be broken down into a number of stages, and rather than just adding mechanisms in a somewhat ad hoc manner it would be better to turn those stages into new MOC releases with each release bringing in more of the mechanisms required to support my end goal.
It was also necessary to provide as clean a codebase as possible from which future development could proceed, and so the focus shifted to historical bugs and backlogged user requests. This was largely successful, but there are still a small number of bugs remaining which are either benign and rarely encountered or for which the cause could not be identified in the time available. There are also a small number of user requests remaining which I either haven't had time to address or which have been deliberately held over awaiting the support mechanisms which would make their implementation easier, cleaner or redundant.
Apart from the ever-present constraint of my own time availablity, pursuing bugs and addressing requests usually involved the co-operation of the original reporter or requester and I was also constrained by their availablity. It was more usually the case than not that I could not reproduce the bug myself and so was left with no choice but to debug remotely by e-mail... and that is a very time-consuming process.
Now that the line in the sand has been drawn, my focus will change from historical bug fixing to new development. There will be some changes which I hope will allow me to do that and move MOC forward more quickly than in the past. And they involve you, the MOC user community.
I will be disinclined to investigate bugs for which insufficient information is provided in the first instance. If you don't provide the basic information needed to begin debugging your report is likely to be ignored; at least, it is likely to be ignored by me. I am hoping that people in the MOC community who are familiar with the particular circumstances and/or environment surrounding a bug report will step forward and either debug the problem or at least triage it to the point where I can be presented with a workable bug report.
I would also like someone to volunteer to act as a co-ordinator for such triage work.
And if you do submit a bug report be prepared to engage with such a co-ordinator or mocmaint in the debugging process if necessary. You can choose to submit it at a time when you will be available to pursue it; mocmaint has no such choice. Users who report bugs and do nothing more or who abandon the debugging effort part way through take time away from more productive efforts.
The aim of the changes outlined in the last three paragraphs are to minimise the distractions of engaging in prolonged e-mail discussions in order to extract the most basic of information. There are also some other contributions the MOC community can make to help me keep focused on development.
I will not be testing new commits as thoroughly as I have in the past. In the past, I have imposed heavily on those few people who have generously given of their time to assist by sending out pre-commit patches in an effort to ensure they work on a variety of platforms. Because most commits will now be driven by new development, as long as they build and pass testing on my system I will be committing them and relying on the MOC community to field test them. If you wish to help with this then you should be technically competant enough to do it without significant input from me and be able to report any issues and suggestions comprehensively and directly to mocmaint. And obviously you will need to track the current SVN HEAD closely.
There are some aspects of MOC which I cannot support effectively myself, and on which I have often been working blind and for which I have been reliant on the goodwill of others to review and test my work. There is a risk that these areas will be left behind or be unintentionally broken by surrounding changes as MOC moves forward and so become unsupported. Technical users of the MOC community might like to adopt one or more of these areas for which they have the capability to support. These areas are: non-Linux platforms, non-Slackware distributions, non-64-bit machines, Internet streams, X-Windows compatibility, Unicode and non-ASCII character sets, TiMidity, Jack, OSS and SNDIO.
There are other less specific areas for which I just do not have the time to support to the level I would like to see them supported. These areas include: the marshalling and maintainance of contributions, trawling the Forum posting for forgotten, uncompleted or fixed but unclosed issues, indexing of the topics of Forum posts, occasional technical research tasks, and the development of more complete documentation (particulary from the user's point of view). Without people offering to undertake this work it is unlikely ever to be done.
If you wish to contribute code then you're welcome to do so, but it is strongly advised that you discuss your plans with mocmaint first so that duplicated effort and clashes with other development work can be avoided. Your contribution should be compatible with MOC, both in terms of overall purpose and in being consistant with MOC coding style. Review existing code and previous commits to learn what mocmaint expects. Ensure that your contribution is functionally complete and well tested. When making a contribution you should plan to stand by it, at least for a while. You should monitor the Forum and be prepared to respond to suggestions and bug reports which relate to your contribution unprompted by mocmaint.
Those who have already contributed patches but have not yet had them committed should expect to be contacted regarding them shortly. Please ensure that your patches are up to date and conform to the expectations summarised above. If you haven't heard anything within a few months then please prompt mocmaint to ensure that your contribution hasn't been overlooked.
So what are my plans for future MOC development?
Until MOC 2.5.0 was released, I kept my plans for future developments pretty quiet. But it's now appropriate that I make them public. The further into future we're looking, the less well developed and changable is the plan. Much of the design work for MOC 2.6 is done and some of it is already coded and ready to be tested; by contrast, the intentions of MOC 3.0 are quite vague and fluid.
As with all plans, these are subject to change; they've changed already as ideas have crystallised and mechanisms become generalised. In particular, there is much work to be done in MOC 2.6 and it's quite possible that it may be split into two or more releases as various aspects of it reach completion and it seems appropriate to have them form a distinct release. In that case, the subsequent releases will be renumbered accordingly.
John Fitzgerald,
MOC Maintainer.