Community Integrated Version

[wleader]

I spent a lot of time the last few days thinking about the various integrated versions that are out there and I think that as a community we can do better if we come up with a plan that will meet the needs of all the interested parties before we just start putting patches together.

What I have in mind is what I am calling a Community Integrated version. The idea is to create a clear set of guide lines or rules for an integrated version. What I have in mind is a version with a manager or integrator who is responsible for the integrating patches that have been selected for inclusion, and creating a publishing builds who works by a clear set of guide lines for determining which patches to include.

Ideally a build will be created periodically perhaps every other month. The process of creating a build will be something like the following:

Phase One - Working with the core developers a recent and mostly stable revision of the trunk will be selected. This revision will be the target revision for all patches that may be included in the build. The purpose here is to make it so all the patch developers are creating their patches against a specific revision to reduce the work on the integrator.

Phase Two - Patch developers will have a period of time perhaps a couple weeks to make their patches compatible with the revision selected in part one. While this adds a little maintenance work for patch developers it has the benefits of keeping the patches nearly current with the trunk, and demonstrates to the core developers that a patch has a maintainer who can help bring that patch into the trunk later.

Phase Three - Patches that have been made compatible with the selected revision and meet quality and security requirements are included in the build and once all qualified patches are integrated, the build is release.

Rinse and repeat. In theory there could be multiply builds at various phases of the cycle at the same time. For example, while the integrator is working on Phase 3 of Build A, Patch developers could be working on Phase 2 of Build B. I think that there could be up to two builds in the pipeline at any given time.

The main goals here are to adopt a rapid release cycle and make integration as easy as possible while providing patch developers clear and simple guide lines for getting their patches included. The reason why I consider this to be a 'Community' version, is that anyone that agrees to the rules can get their patch included.

I would like to admit that my motivations are somewhat selfish. The next patch I want to test affects multi-player, and just about the only way to get a patch tested in a multi-player game with real players is to have it included in and Integrated version. So If I am going to go through the trouble to make an integrated version with my patches, why not open it up to other developers like me?

I'm ready to volunteer and attempt to run though a build cycle like this, but before I do, I would like to hear what other developers think.

[Rubidium]

Isn't the "community" version with patches that follow certain (strict) guidelines to ensure stability and things like coding style called "trunk"?

The whole reason why the Integrated Nightlies exist is the fact that there are quite a lot of patches that are either not completely finished or do not meet the required standards to be included in trunk, but some people want to play with a lot of them anyway. So somebody integrates them into a single patch and (s)he releases that, usually without any proper review of the patches and how they (do not) work together.

When you want to add proper review and those guidelines, especially the ones to ensure stability and maintainability, to the integration process you'll most likely end up with virtually no patches or patches that are currently being included into trunk.

This negative attitude of me is because of the experiences I have with previous Integrated Nightlies and the patches that were included into there. For example the MiniIN had a desync issue basically from the beginning, but nobody *ever* reported it and it was only found when I accidentally stumbled upon the code when trying the update the MiniIN. The feature causing the desync was used by many people, so it could not have been a hidden desync because of the sheer ease to get a desync.

Another case that I can remember is when there was a patch that was in principle good, but there was one small (design) issue that the person refused to solve. The patch got included in some Integrated Nightlies and people kept complaining about that.

The final thing is that I got the feeling that once a patch gets into an Integrated Nightly most of the authors of that patches stop maintaining the patch and leave the maintaining to the integrator, which means the integrator becomes effectively the maintainer/bugfixer of lots of patches at once. This has been the "death-sentence" for at least two Integrated Nightlies and I fear that it is going to happen again.

A major problem I see in the proposed method is the fact that you release a probably one to two month old version of trunk that has quite a few bugs that are already fixed. People will complain (again) about those bugs and backporting the bugfixes made to trunk in the mean time costs a lot of time. That will then only delay the release of the integrated version, which causes more bugs to be fixed in trunk...

[wleader]

First Rubidium, Thanks for the good feedback.

Isn't the "community" version with patches that follow certain (strict) guidelines to ensure stability and things like coding style called "trunk"?

Yes the trunk is. However not just anyone can commit a change. That is for the most part a good thing because it keeps out bad code. What I have in mind has more relaxed guidelines. I don't see this as something that supplants the trunk, but instead is more like a proving ground for things before they are ready to go into the trunk. Its purpose is to compliment, not compete.

When you want to add proper review and those guidelines, especially the ones to ensure stability and maintainability, to the integration process you'll most likely end up with virtually no patches or patches that are currently being included into trunk.

This is a valid concern, which is why I am asking the opinions of patch developers. Personally I feel like if I was told that as long as my patch works on Revision X of the trunk that it could be included, I would make that effort because from my perspective, I'd like to see my patch available to players in an easy to test form (without the hassled of posting my own builds.)

This negative attitude of me is because of the experiences I have with previous Integrated Nightlies and the patches that were included into there. For example the MiniIN had a desync issue basically from the beginning, but nobody *ever* reported it and it was only found when I accidentally stumbled upon the code when trying the update the MiniIN. The feature causing the desync was used by many people, so it could not have been a hidden desync because of the sheer ease to get a desync.

Another case that I can remember is when there was a patch that was in principle good, but there was one small (design) issue that the person refused to solve. The patch got included in some Integrated Nightlies and people kept complaining about that.

Each time the integrated version would get built, the code would be discarded and branched again from the trunk. The reason is for just the issues you mention; to ensure that updates to the trunk find their way into the integrated version. Basically the integrated code is throw away code. Its not meant to be kept or maintained for the long term, its temporary at best to ease the testing of patches.

The final thing is that I got the feeling that once a patch gets into an Integrated Nightly most of the authors of that patches stop maintaining the patch and leave the maintaining to the integrator, which means the integrator becomes effectively the maintainer/bugfixer of lots of patches at once. This has been the "death-sentence" for at least two Integrated Nightlies and I fear that it is going to happen again.

One of the ideas I am kicking around is that each time the integrated version is rebuilt is to require patch authors to provide and updated version of their patch. If they fail to do so, it not included. This would force the original patch developer to do the work of keeping their patch up to date so long as they want it to remain included. This means that the integrator is not the maintainer of the patches.

A major problem I see in the proposed method is the fact that you release a probably one to two month old version of trunk that has quite a few bugs that are already fixed. People will complain (again) about those bugs and backporting the bugfixes made to trunk in the mean time costs a lot of time. That will then only delay the release of the integrated version, which causes more bugs to be fixed in trunk...

Now this is a valid point, but when a bug is identified in the Integrated version that was inherited from the trunk code, it can be effectively ignored if it has already been reported (and maybe fixed) otherwise the bug can just be reported. The code pulled from the trunk is regularly refreshed, and the patches are also refreshed each time. Patch bug fixing falls back on the original patch developers, and trunk bug fixing falls back onto the capable shoulders of you an the other core developers.

I hope I am communicating effectively.

[Alberth]

What I have in mind is what I am calling a Community Integrated version. The idea is to create a clear set of guide lines or rules for an integrated version. What I have in mind is a version with a manager or integrator who is responsible for the integrating patches that have been selected for inclusion, and creating a publishing builds who works by a clear set of guide lines for determining which patches to include.

Euh, I think we already have this, it is called trunk, and is managed by the devs (devs are also part of the community). Apparently you are not happy about this setup, or you wouldn't be proposing another development line next to (or prior to) trunk.

The next patch I want to test affects multi-player, and just about the only way to get a patch tested in a multi-player game with real players is to have it included in and Integrated version.

Given that your objective is to get your patch into trunk, setting up another development line is not going to help you forward.

If you follow the same requirements as for trunk, you are wasting time, since puttting it into trunk is then faster. If you use less high requirements, you have to move up to meet the trunk requirements afterwards. In both cases you don't gain anything.


Maybe instead of jumping to the solution, we should first discuss what exactly the problems are that you are experiencing, and find an alternative way of dealing with them?

Sincerely,
Albert

[LordAzamath]

The coders will not concentrate to get to your build for each time if you force them to update.. After all it was you who wanted them in weren't you..
And for multiplayer-testing just join #openttd at irc.oftc.net, name the patch and start a server.. I doubt you wouldn't get players from there.

[wleader]

Euh, I think we already have this, it is called trunk, and is managed by the devs (devs are also part of the community). Apparently you are not happy about this setup, or you wouldn't be proposing another development line next to (or prior to) trunk.

Albert,

I find it interesting that you and Rubidium make the same statement that what I suggest is basically the trunk, so perhaps I am not being clear. In other programming projects I have worked on, the Trunk was not the place to just try things out. You make a branch, change it, test your changes, and if you are satisfied, you merge those changed back into the trunk. In the other projects I have worked on, code didn't go into the trunk unless it ready to be used by the customers. I recognize that not all projects are run the same way, so perhaps things are different for OTTD.

Random Developer can connect to the subversion server, pull down some source and make changes. I've done this, and anyone can do it. What everyone can't do is put whatever changes they want into the trunk. There are gatekeepers to prevent anyone from committing code. I can either submit my code for inclusion and work with those gatekeepers or I really have to, I can fork the code. This is the way open source works, I have no problem with that.

This process works fine for including mature patches but I want to consider Immature patches. I want to provide a better way for patches to be tested on the road to maturity. For example I mentioned my next patch affects multi-player. I'm wanting to work on the code that calculates profit as it relates to distance. Log into any multi-player game an you will see long haul coal lines that pass by nearer power stations to deliver cargo to a power station clear across the map. I want to stop players in multi player games from abusing that. I can test that to some extent on my own machine, but to test its affect on multi-player games I would need to publish a build (because most players can't patch and build their own) and run a server. There is very little motivation for the average player to download a build that has my one patch in it and test that. However the integrated versions like MiniIN, ChrisIN, and now Gonozal's Patch Pack are very popular. I had a few patches included in ChrisIN and when that happened I was able to run a ChrisIN Server and see how my patches affected multi-player games, and people actually connected and tried things out. As a result I was able to fine tune things that I would have otherwise not been able to test. My point here is that getting an immature patch into an integrated build like that is great for testing.

Given that your objective is to get your patch into trunk, setting up another development line is not going to help you forward.

If you follow the same requirements as for trunk, you are wasting time, since putting it into trunk is then faster. If you use less high requirements, you have to move up to meet the trunk requirements afterwards. In both cases you don't gain anything.

Sure, I'd like to see my code make it into the trunk eventually, but I don't expect it to get in until it is complete and proven. What I have in mind the requirements for getting a patch included would be fairly relaxed, because I want to recognize that developers want to test immature code. in my opinion, the trunk is not the place for testing immature code. I want to create that place.

Maybe instead of jumping to the solution, we should first discuss what exactly the problems are that you are experiencing, and find an alternative way of dealing with them?

Sincerely,
Albert

For the most part I wouldn't say I am having problems. Like I said above, I can get the code change it and put a build out any time I like. The difficulty is testing my changes with real players. I know what it's supposed to do but players always seem to find a way to break it. Getting a patch into one of the integrated versions seems to be the best way to get it well tested short of actually getting it into the trunk. From my perspective having a patch in an integrated version is a stepping stone on the path to getting a patch into the trunk.

I guess in short the problem I am trying to address is how best to get patches tested that aren't quite ready for inclusion into the trunk.

The coders will not concentrate to get to your build for each time if you force them to update.. After all it was you who wanted them in weren't you..

This integrated version would be different because the integrator doesn't just include the patches they are interested in. The reason for such a version is not so that I can play with both the Foo patch and Bar patch in the same build. It would be done so that the authors of the Foo and Bar patches can more easily get their patches tested by a wide range of users. Patch authors would submit their patches for inclusion, rather than be selected for inclusion.

[LordAzamath]

Well as I said, if you want more testing, you can always set up a game in IRC channel.. And For usual testing the Gonozal_VIIIIN is widely used too..
BTW FooBar is a respected member here, although IIRC he has yet to submit a patch ^^

[wleader]

Well as I said, if you want more testing, you can always set up a game in IRC channel.. And For usual testing the Gonozal_VIIIIN is widely used too..
BTW FooBar is a respected member here, although IIRC he has yet to submit a patch ^^

People in IRC that wanted to play would still need to download a specific build, which for people inclined to use IRC is fine, but the more casual player is unlikely to do so. It does seem though that many people download the integrated versions.

As for what Gonozal is doing, which I admire, still has the same problem. I can ask him include my patch, but whether it gets included is down to fuzzy things. There are no firm rules about inclusion. Instead of the answer to a patch inclusion being 'If I feel like it', or 'maybe if I have time', I'd like for the requirement to be 'Give me a diff file for revision X that introduces no obvious errors by Friday, and I'll add it.'

Perhaps the thing is that the integrated versions thus far have been done as a service to players. Instead I think we could make an integrated version that is done as a service to patch makers. Patch makers who make the effort to provide an updated patch would get included instead of patches that are most in demand getting included.

[Roujin]

Well, it's certainly an interesting approach you're suggesting here. I can see some problems here though:

No real testing: Players will just play with the integrated version, not really test something and make (bug)reports to the patch author. At least the casual players; but the others will compile a version to test your patch anyways.

Mixing together patches is bad for testing: When a bug occurs, whom should the player report to? He can't know what patch caused that bug, so he'll report to the integrator -> he gets bugfixing work.

I guess the casual players won't be happy with the approach "include what is updated in time" instead of "include what is wanted most" because they, obviously, want what is wanted most.

Patch authors may indeed be tempted to not improve their patch anymore as soon as it is "good enough" for the community integrated version, just update it every cycle.


---
That's just what came to my mind when thinking a bit about it... i'm not generally against it though - if you or someone started this experiment, i'd contribute with (one/some of) my patches and see how people respond to it...

[athanasios]

I think it is better to have a Community IN release than various INs that just die after some months. Where is MiniIN, where is Challenge Spinoff? Dead. Chris IN? In coma. And I suppose the same will happen to Gonozal's IN. The problem is that usually there is only one person behind the IN and he cannot do this for ever. I suggested an official "dirty trunk", but this was rejected from the developers. If others are willing to manage such a project, updating on a weekly basis, I would be very happy. More rare updates would turn away players.

regards
athanasios

[l_Blue_l]

As i see it MiniIN was the best integrated nightly out there but failed as it was unmaintainable. Any IN needs to make it easy for the team of developers be hide it but integrating many different patches together can make it extremely hard as there is likely to be many conflicts. One way around this would be to have a base level of the Community Integrated Version which includes some of the larger patches and requires the patcher to get there patch to apply to this base version to get included to the IN in so reduce the amount of conflicts the team would incounter. More planning would need to take place to get an svn but i believe it could work.

[jez]

Isn't the "community" version with patches that follow certain (strict) guidelines to ensure stability and things like coding style called "trunk"?

No, because patches that some people want but the main devs don't don't make it in, either. For example, Copy/Paste is pretty much finished and many of us use it all the time in our games, but it isn't going in because some people think it's 'cheating'.

[belugas]

Well... I personally think that, as devs, we have the right to approve or reject this or that patch, for our own reasons.
And I don't think that popularity of this or that feature makes it worth inclusion.
In the end, we will have to battle ourselves with the code.
Look at time table. It may have seen good at the time, but the number of bugs was quite staggering.
Many bug fixes bear that name.

And I wold like to point out that people will never be happy with any decision been made. There are pros and cons to every inclusion. Don't like the system? Do a fork and maintain it. Sorry, but that's the way.

[Rubidium]

Isn't the "community" version with patches that follow certain (strict) guidelines to ensure stability and things like coding style called "trunk"?

No, because patches that some people want but the main devs don't don't make it in, either. For example, Copy/Paste is pretty much finished and many of us use it all the time in our games, but it isn't going in because some people think it's 'cheating'.

I have *much* more problems with the design (and (un)maintainability because of that) of said patch than the whole 'cheating' stuff. Why I haven't fixed the design and such is because I do not personally feel the need for it, so I cannot be bothered to fix the design. Furthermore I have talked about the design issues I had with it at least once.

Actually, most patches that are 'out there' that I know about and are not in trunk are not in trunk because of coding style, design, general unfinishedness or major bugs. Note: I know very little about any updates to patches or new patches made in the last months as I did (and still do not have) the time to continue coding for OpenTTD.

[jez]

rubidium: Well ok, but maybe you devs should 'officially' make 2 comments on each proposed patch; one on the quality of the code itself, and one on the functionality of the patch. If the former is bad and you're able to promise that the latter is acceptable to go into the trunk, people might be more motivated to fix up the code.

[belugas]

jez, if i remember correctly, every time we made any comment on your patch (the facepart one), the reception of these comments were always followed by an endless moaning about our code style, about the use of macros and much more.

Commenting each and every patch is quite useless, as frequently, it ends up on protests or on sterile justification of the usefullness or the lack of dev interest on the commented patch. I tried it a few times, and i ended up getter really fed up. So, no thanks.

Only when a patch seems very interesting, and there are a few, do I take time and interest on it/them. and it ends up on talking about it on IRC or on PMs

[DJ Nekkid]

well, if we look at the last months (from october to now) there have been aprox 200 new rev's per month on average (226 to be exact)

So for this to work, i suggest the following:

The "core" patch-devs should get some webspace somewhere.
And for every 200th rev (that is, aprox a new one every 3 or 4 weeks) the "want-to-be-included"-patch devs have for example 3 days to update to the proper rev. After all, it's not that often new "major" features come out. So a new "Pack" every now and then should be sufficient imho...

[jez]

Commenting each and every patch is quite useless, as frequently, it ends up on protests or on sterile justification of the usefullness or the lack of dev interest on the commented patch. I tried it a few times, and i ended up getter really fed up. So, no thanks.

Shame you feel that way, but my suggestion still applies to other devs. Really, it doesn't eat up that much of your time just to make some forum posts about patches. If people abuse it, so what, just ignore their posts.

Only when a patch seems very interesting, and there are a few, do I take time and interest on it/them. and it ends up on talking about it on IRC or on PMs

Yeah, IRC, I remember that. It's where you get kickbanned for saying anything.

[DaleStan]

Yeah, IRC. It's where you get kickbanned for saying anything.

Funny. I've never been kicked from either channel.

[richk67]

... other devs. Really, it doesn't eat up that much of your time just to make some forum posts about patches.

So you think it doesnt eat time to make a reasonable dev assessment of, say, YAPP or Subsidiaries. YAPP is over 4000 lines. Lets say review it at 20 lines/minute, that is still 3 hours just code reading - not even testing how/whether it works. The old Subsidiaries patch - much loved by those who whine lots and code little - was more than that. (I had more nags as MiniIN integrator about "why wont you recommend Subsidiaries for trunk?" than for any other component. My impression was that it was too large a patch to be accurately assessed.)

Bottom line is: if the devs arent convinced, the devs arent convinced. Its a pity that some patch authors cant accept their patch just aint ready/suitable/too niche/etc.