[Cs-dev] Csound release management, esp re Csound 6
| Date | 2012-02-13 00:06 |
| From | Iain Duncan |
| Subject | [Cs-dev] Csound release management, esp re Csound 6 |
| Attachments | None None |
| Ok, I will start by apologizing for my less than diplomatic tone regarding build issues on the development list so far. Honest apologies. I will try to keep this email to facts and questions, and humbly offered opinions. Posting to both lists as I believe there is a good chance that there are users who have also been frustrated but are not on the dev list and may wish to weigh in. From what I can tell from Steven's thread on Csound 6, a major thrust of Csound 6 is to improve Csound as a library that can be used as an audio engine by other apps. This is great news to me, that's what I'm doing. My project is a C++ app using Csound as one possible output layer. This does mean that Csound is seriously putting itself forth as something that can be reliably used as a dependency for other projects, and I believe that has implications.
I am proposing that if Csound is going to be targeting this segment, as part of this plan, an improved policy for Csound source code release management is required. I would hazard that developers using csound as an engine will likely be providing instructions for their developers to build from source, and likely to users as well in the initial alpha or beta stages of a project.
In the last two months, I've had two production snapshot releases not build, and another had debug printf output that wasn't supposed to be there and rendered it unusable for the project. These were Csound 5.14.2 for linux, Csound 5.15.0 on OS X, Csound 5.16.1 on OS X. To clarify, all were production tarballs, not pulling from git. I was advised to fix from git, however I have been told that the git trunk is not stable and not guaranteed to work 100% of the time. ( reasonable for trunk ). This has been very frustrating to me, and I apologize for not handling it as gracefully as I could have. That said, were my project at the point of alpha releases to others, it would have been frustrating for my users and developers too.
It is my personal belief from my observation of other projects that I work with on a daily basis with my python business, that projects being used as dependencies by other projects ( as Csound is intending ) generally make sure that the production release always builds and always passes all the regression tests. There are indeed a number of great tools out there that are free and help make this possible. The process I see the most is as follows:
- a "we're getting close to a release" announcement goes out on the mailing list ( this happens with Csound ) - trunk is branched for a release candidate - the rc branch is tested by a build system or by users/developers who do this
- any issues are fixed in the rc branch only, nothing else goes on in this branch - when the branch is known as passing all tests and building on all targeted platforms, the release manager then creates a frozen production snapshot and releases
- the bug fixes from the rc branch are then merged back into trunk - development continues on trunk and the process begins again It does not seem like this is happening with Csound. So, my questions are:
- do others think this is important? am I in a minority, or are there others who are concerned and are just not saying anything? - do others share my opinion that this will become more important if Csound 6 is meant to target developer users of the CsoundAPI?
- is there a current release policy and if so, what is the release policy? - why is the release procedure the way it is right now? not a rhetorical question, I mean what are the real reasons? IE lack of resources, time, experience with continuous integration tools, etc? What is the bottleneck?
- what do we need to do to make an improved release policy that guarantees production releases build 100% of the time and pass all tests? IE, what can provide to help this happen? Some things I can think of that could be done: - a page documenting the release policy and who is in charge of what (is there a csound release manager? could there be one?)
- adoption of at least a system of branching and merging for each release. This would help even in the absence of a continuous integration system, as people could build on virtual machines to test.
- Maybe flagging fewer releases as production release if the above is too onerous - setting up a buildbot system that builds nightly from trunk and is used to check release candidates - we could approach various hosting companies who like to demonstrate that they support open source and asking for donation of VPS's if resources are an issue
- a continuous integration system where trunk is built nightly so that people checking in code that breaks the build are alerted right away, before we even branch for releases
Feeback please. iain
|
| Date | 2012-02-13 02:35 |
| From | Iain Duncan |
| Subject | Re: [Cs-dev] Csound release management, esp re Csound 6 |
| Attachments | None None |
| Answering myself, as I just thought of another way to look at this. Csound has an API to allow other apps to embed it and have it as a dependency. When I use Csound in this way, my relationship to Csound is the same as Csound's relationship to its dependencies, libsndfile, fltk, portaudio, etc. Personally, I think the future of csound is in this direction, and that this is very important, but YMMV there.
I personally believe the Csound development community should hold itself to the same standard of reliability as we get from those packages that Csound depends on. We don't ever have to worry about whether libdsnfile, jack, scons, fltk, qt, portaudio, etc will build. Their maintainers make sure that the canonical production release is always dependable, and that is taken into account when choosing dependencies. I evaluated many audio output layers for my app, and chose Jack because I know the truck number is good, and it always works. I don't have to get on the jack mailing list or keep track of what's going in there unless I'm interested, and I wouldn't want to have to get on list for libsndfile to have to figure out how to build Csound.
So perhaps this is a growing pain of csound becoming an audio engine library as well as a product. I believe Csound release management should be taken just as seriously as it is by our upstream components.
thanks for listening. iain
|