My general opinion on that topic:
If one is willing to start a project as an "official" release provider, step forward. I think it can be quite "easy", skills required are:
- you need at least to be able to compile wxWidgets and C::B yourself using the official sources and build tools
- you need to be able to update / run NSIS on Windows to create the installer
- you need to be able to provide packages for linus (e.g. deb) -> forum people may help here
For the setup I can imagine:
- we candidate a certain nightly for an official release
- after a few more nights (hehe) if no true show-stopper occur we agree that this is a new release candidate
- all packaging is done (including setting up a new version number)
- releases are officially provided to the C::B dev team for testing (basically "installing")
- releases are delivered to a C::B admin and will be propagated through our server
We could agree on doing that at round-about every quarter or half of a year. I'd propose the latter which means two times i the year the volunteer needs to get into action.
So... Who is willing and has the skills and time to do that?
Keep in mind: This should *not* be a short term support, but rather a long term support.
I'm not familiar with how this project is organised, only that it's an excellent balance between producing a useful IDE, that's not fatter then mozilla in the process :-D.
This all involves leadership and planning, to practically quote Kerensky, a good solution applied with vigor immediately is better than a perfect solution ten minutes later. Someone in the development team should be tasked with creating a suitable OPORD
0, outlining what needs to be done in order to get a `release` deployed. Things like what parts of the website need adjusting, how it's to be tested, which OS/PMS bundles to be created, et cetera. Doing that won't take long, assuming anyone knows what needs doing, and makes bringing support personal onboard a more trivial affair - ten minutes typing saves weeks out of a decade. Once that's written, wikify it to the public and edit it as FRAGOs
1 are required.
It should be simple to define some kind of formal release policy and add it to the wiki. If C::B development is actually more then an occasional commit out of the blue, it could easily be arranged for a test cycle to be run every X months on the trunk (I assume all the devs run trunk or branches), then branch off a release from it once the cycle is completed: all show stoppers fixed since test cycle start, and hopefully no commits since breaking more then they fix. The nightly builds are kind of good for that
. If C::B has much more regular pace of development, you could always just make a release equal to any suitable snapshot of the trunk at regular intervals, and just say the hell with it.... much like grabbing the latest and unstablist out of someones git repository.
Most of the website issues, could likely be scripted away with a bit of effort
2, and suitable munging together to reduce the pain threshold for making the release files. It all depends on the particulars that are defined as necessary. It really depends on the effort people are willing to put into quality release engineering.
Just my two bits.
footnotes:
0: OPerations ORDer, a multi-paragraph order describing a military mission. Typically given a concise review of the situation, mission concept, execution details, and any prerequisite coordinating or logistical instructions.
1: FRAGmentary Order, some what like a hotfix or patch with updates/corrections to an OPORD.
1: depending on environment this may be easier or harder (e.g. needing to write a custom web robot)