My first post after months of lurking...
Although I've been interested in getting involved with OTTD development for a long time, only now my job grants me enough free time to get back to programming in the open source domain.
Since I've been a professional programmer for 15 years now, that will be a busman's holliday for me, but who cares.
During the last 4 to 5 years I've been "promoted" away from the day-to-day coding to project leader and test supervisor duties. I don't mind the payment upgrade, but I miss getting my hands dirty on some serious coding.
Since I've been juggling whole projects lately, I've learned a thing or twelve about project management, so maybe I can offer some suggestions.
First of all, a trunk-fork would be a crippling blow to the project really as NewGRF's would start to become incompatible over the time. Not all GRF authors will bother checking their creations for compatibility with three versions (TTD-Patch, OTTD, ChillTTD). Not to mention that it would probably split the fan base into those, who stay with the original OTTD and those, who follow the forked patchpack version. Eddi
offered the most sensitive option, I think. A patch as massive as CargoDist will probably never make it into the trunk. Programmers are notoriously territorial animals, so it is a tough sell to get the major trunk players to accept such a complex inclusion. What is possible, however, is to synchronise the patch pack to the trunk versions.
Let's say you decide to "restart" the patch pack. To get that off to a good start, you would select a bunch of patches to include, and integrate them into the current major trunk revision, which would be 1.2.0. For clarity reason, you would call it 1.2.0 as well. Once it is stable, the features are frozen, which means that no new features will be added in any of the patches. The only development that will be going on in this branch, is bugfixing and compatibility fixing to the minor trunk releases, like the current 1.2.1.
Simultaneously you have a second branch, lets say you start that at revision 1.2.50. That way the revision number clearly shows what's what. 1.2.<50 are "stable" releases correlating with the stable releases of mainstream OTTD and 1.2.>50 are the bleeding edge versions, which include the same bugfixes and compatibility fixes as the <50-revisions, but also get new features. This might create a bit of a work-overhead, as you have to back port all bugfixes from the >50 revisions to the <50 revisions, but you can always release a "stable" ChillPack!OTTD whenever OTTD releases a minor trunk release.
Those of a more adventurous disposition can meanwhile choose to plug the latest 50+ revision into an OTTD nightly. Inclusion of new patches into the pack would only happen in the 50+ revisions, keeping the 50- revisions stable. As I said, it is a wee bit more work than absolutely neccessary, but it will give the ChillPack users the option of playing a reasonably up-to-date version in comparison to the vanilla release.
The critical question is whether or not a 1.2.0 based ChillPack will be stable before the "trunkies" release 1.3.0. If not, it would make sense to start development at the current trunk-nightly and have no stable release. The first stable one would then be ChillPack 1.3.0.
On a technical level I would suggest to depart from the monolithic patch approach. I would suggest to keep each patch seperate. That'll probably add a gazillion #ifdef's to the source, but it also allows to disable patches at source level (via ./configure parameter). That makes it easier to discontinue patches that are terminally broken or have found their way into the trunk. Imagine the trunk does some major changes to map handling, which would break the heightlevels patch. Instead of nerfing the whole patch pack, you could temporarily disable it via hardwired ./configure option. All other patches in the nightly would still work and those, who want the heighlevels patch can revert back to the latest stable release. Once the heightlevel patch has been fixed, it can be re-enabled in the next nightly.
That got a bit long for a first post, didn't it
Hope I didn't come across too head-teachery, just wanted to offer some advice from experience with commercial project management.