Transport Tycoon Forums

wleader wrote: There is an assertion error in the multi-engine normalization patch, and kaan seems to be away so I may need to remove the patch. Sadly this problem didn't express itself until the game had been running for a while so it got past my admittedly brief testing.

If you think my patch is making any trouble at all, then please feel free to remove it
For future reference it would be helpfull if you make a bug describsion in the patch thread.

Patches submitted by 3rd parties on behalf of an author will not be accepted unless the original author provides consent.

What if the original author has gone missing. I just updated the better graphs and would like them included. Zojj hasn't posted in 4 months. Is that long enough to assume he's gone?

I assume, its more the problem, if you take over the credit for the patch. If you write something like "patch based by Zojj", then there won't be a problem. imo.

Edit: won't you first make the "test run" really running, it contains still the bug. Its just, if the Build1 has also such a bug, there will be also no bugfix?

Greets
Ammler

n/m

Ammler wrote:I assume, its more the problem, if you take over the credit for the patch.

If you write something like "patch based by Zojj", then there won't be a problem. imo.

This is mainly because I am uncertain about the legal standing of a patch. while the code itself is GPL, and its license is clear, what the license is on a patch is not. The problem is that the GPL stipulates that if a modified version of the work is distributed, then the GPL takes effect. It can be argued that a patch file by itself is not a modified version, and is only instructions on how to modify the work. If that is the case, the GPL can not be assumed to apply to the patch itself. Until someone can clarify this for me, I think permission to redistribute the patch should remain a requirement.

Ammler wrote: Edit: won't you first make the "test run" really running, it contains still the bug. Its just, if the Build1 has also such a bug, there will be also no bugfix?

Having run through the test run it became clear that a bug fixing phase will be required in order to produce a decent build. There was some question about which patches (or the trunk) was to blame for the bugs in the test run. A bug fix phase wasn't planned for the test run. It's not exactly clear but build 1 will have a bug fixing phase.

wleader wrote:

Ammler wrote: This is mainly because I am uncertain about the legal standing of a patch. while the code itself is GPL, and its license is clear, what the license is on a patch is not. The problem is that the GPL stipulates that if a modified version of the work is distributed, then the GPL takes effect. It can be argued that a patch file by itself is not a modified version, and is only instructions on how to modify the work. If that is the case, the GPL can not be assumed to apply to the patch itself. Until someone can clarify this for me, I think permission to redistribute the patch should remain a requirement.

That would mean, if we have a patch that adds a great feature and everyone agrees they want it and the author goes missing for whatever reason, that patch would be lost, unless someone rewrites it from scratch.

wleader wrote: This is mainly because I am uncertain about the legal standing of a patch. while the code itself is GPL, and its license is clear, what the license is on a patch is not. The problem is that the GPL stipulates that if a modified version of the work is distributed, then the GPL takes effect. It can be argued that a patch file by itself is not a modified version, and is only instructions on how to modify the work. If that is the case, the GPL can not be assumed to apply to the patch itself. Until someone can clarify this for me, I think permission to redistribute the patch should remain a requirement.

May I cite from the license:

COPYING wrote: 2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.

c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)

First of all, it speaks about distributing the modification, which the patch certainly represents. On the other hand, to obey to the license word by word, you would also have to enforce a and c. Have you ever seen a patch that does? So, you should not be that strict or otherwise you don't have "legal patches" here.

My proposal: The original patch author should be asked, but if s/he is not around here and does not answer, but has neither deleted his patches from the forum posts nor expressed that his/her patches should be used in such a way, we should assume that integration into a combined patch is okay for the author as long as due credit is given.

We could just put a notice that reads something like 'The submitter agrees any patch submitted is licensed under the GNU GPL, the same license as OpenTTD itself.' That way the onus is on the submitter.

I would be curious to hear how the core developers handle licensing on patches that get accepted into the trunk. Do they just assume that if the patch has been submitted on flyspray it was submitted as GPL code, or do they get the author to explicitly grant permission for it use, or some other procedure?

Well most often there is some communication between the devs and patch writers going on on irc. But an explicit question if it were okay to include this to trunk...? I think no.. I mean it's pretty clear that normally, if anyone writes a patch for this game, they are fine with it being included in trunk.

wleader wrote:I would be curious to hear how the core developers handle licensing on patches that get accepted into the trunk. Do they just assume that if the patch has been submitted on flyspray it was submitted as GPL code, or do they get the author to explicitly grant permission for it use, or some other procedure?

They assume it is GPL, at least, they don't ask permission to include patches posted on flyspray or on the forums. And why would they, if someone posts a patch, he/she does that to improve openttd.

And read section b) again from the license file

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed (...) under the terms of this License.

So I think you can safely assume all patches posted here are under GPL.

PhilSophus wrote:On the other hand, to obey to the license word by word, you would also have to enforce a and c. Have you ever seen a patch that does?

I would consider a patch file to be pretty prominent notice of what got changed when. What is "Everything in the patch" and when is "When you typed 'patch -p0 < something.patch'".

I was attempting to do some work with the patches already submitted for build 1, and I've run into something that we might want to change for the next build. When Integrating the patches in the past I've found it is easiest to run through the patches in revision order.

Lets say for example you have three patches made against trunk revisions 12733, 12766, and 12810 (very relevant example isn't it?). In this case I would start with 12733, and apply the first patch. Then update the code to 12766, and apply the next patch. This is repeated for each patch desired, with the final step being to update to the head revision of the trunk.

With build 1, Submissions are being accepted for any revision after 12733, but not necessarily in order which will make things just a little more difficult to integrate. So perhaps for build 2 it would make sense to change the requirement that submitted patches must be for a revision equal to or more recent that the last submitted patch? That way the revision order of the patches would match the submission order.

I think this would make integrating the patches easier, and is only slightly more work for the submitter. Most submitters seem to be submitting patches made against the current trunk anyway.

Any thoughts?

What i learned from making my patchpack is that if you try to integrate several patches some will always be 50, 100 or more revisions behind. Especially when you do it your way, i.e. having a submission period. Latest changes in trunk have been quite a few code style changes or restructuring of files. While someone with a little bit of experience can usually apply a patch anyway, it's always better if the patch author, who knows what's going on in that part of the code, keeps it up to date.

So I'd suggest you don't make submission revs but ask the submitters to edit their post and keep those patches up to date there.

wleader wrote:I think this would make integrating the patches easier, and is only slightly more work for the submitter. Most submitters seem to be submitting patches made against the current trunk anyway.

Any thoughts?

yes, you may simply ask that the submited patch was made against the current trunck at the date of submition...

We hit a bad moment with this integrated build with so much changes going on in trunk.

I don't see an easy solution to this unless you want to make a rule that all submitters upgrade their patch to then current trunk HEAD in a very short period (say the last 24h) before submission deadline. But why choose a 10-day submission period then after all?

@wleader:
I'll have to do a small fix for my Improved Loans patch, which I already posted for Build 1 (Fixing compiling problems with VC2005). Which revision would you prefer the fixed one to be against? The one the currently posted is made against (12795) or current trunk HEAD (whatever this is this evening )?

PhilSophus wrote:We hit a bad moment with this integrated build with so much changes going on in trunk.

Actually, I was going through this morning and did a little testing, and despite there being over nearly 100 revisions to the trunk since submissions were opened, I've not had any trouble integrating patches thus far. Granted I am about two thirds of the way through the submissions, and I have brought my copy only to r12795. I don't think the frequent trunk revisions have been a problem at all.

PhilSophus wrote:I don't see an easy solution to this unless you want to make a rule that all submitters upgrade their patch to then current trunk HEAD in a very short period (say the last 24h) before submission deadline. But why choose a 10-day submission period then after all?

I thought it was 7 days, plus a little to make it end on midnight gmt. But your point still remains. I figured a week would allow just about anyone a chance to contribute no matter what their schedule might be. Really the goal is to get patches that are relatively up to date. Its pretty easy to update a patch thats a week old compared to updating a patch that is months old. I accept that there may be a small amount of updating to do to bring any patch up to trunk, but if its just a few days worth of revisions, thats an amount of work I can deal with (actually updating a patch thats only a few days old is often almost no work.)

PhilSophus wrote: @wleader:
I'll have to do a small fix for my Improved Loans patch, which I already posted for Build 1 (Fixing compiling problems with VC2005). Which revision would you prefer the fixed one to be against? The one the currently posted is made against (12795) or current trunk HEAD (whatever this is this evening )?

When in doubt, I say update to the head revision. Generally you (as the developer and or submitter) are more familiar with the patch than I am. If there are any problems with bringing the code up to the head revision, something that will be done anyway, you are in a better position to resolve the problem than I am. It might make me sound a little lazy, but I didn't start this project so I could do all the work. One of the goals is to distribute the effort of making an integrated version among multiple people.

Edit: ah, thank you, placed in the other thread

But you basically already have such a community IN, called trunk, where patches also be excluded from unless they suit the coding style. And as with all the other INs, I don't believe this one will last any longer

yorick wrote:I'd like to submit my flags in client list patch:

Please Submit your patch in This Thread.

wleader wrote:

PhilSophus wrote:We hit a bad moment with this integrated build with so much changes going on in trunk.

Actually, I was going through this morning and did a little testing, and despite there being over nearly 100 revisions to the trunk since submissions were opened, I've not had any trouble integrating patches thus far.

Nice to hear.

wleader wrote:

PhilSophus wrote: @wleader:
I'll have to do a small fix for my Improved Loans patch, which I already posted for Build 1 (Fixing compiling problems with VC2005). Which revision would you prefer the fixed one to be against? The one the currently posted is made against (12795) or current trunk HEAD (whatever this is this evening )?

When in doubt, I say update to the head revision. Generally you (as the developer and or submitter) are more familiar with the patch than I am. If there are any problems with bringing the code up to the head revision, something that will be done anyway, you are in a better position to resolve the problem than I am. It might make me sound a little lazy, but I didn't start this project so I could do all the work. One of the goals is to distribute the effort of making an integrated version among multiple people.

Well, I'm pulling the patch to current trunk anyway when changing something, so no big deal anyway. I just edited my submission in the Build1 thread to contain the fixed version.

I thought it would be more appropriate to reply to this post in this thread.

Ammler wrote:we should really think about save compatibility to CIV Build2, So something like a table which patch adds settings, which one changes map format, so we see easy which patches should be included to have a save compatibilty.

Generally I like save game compatibility, but I wonder about how difficult something like that would become. There is the problem of what to do with a setting for a patch that was in the prior build, but wasn't submitted for the current build. Someone has to write code to deal with the extra data in the save file. Ok, maybe thats not too hard, but its extra work for someone. If it is a patch like YAPP, what happens to all the Path based signals on the map?

I feel that trying to do save game compatibility would make us look like we are trying to compete with the trunk, and distract from what I feel is the main goal of CIV. It also feels contrary to the resubmit each build rule. If a patch is not resubmitted, but put data in a save file in an earlier build, we would forever be dealing with that patch in future builds. These are the kind of issues that have to be addressed when adding a patch to the trunk. Basically once you add something to a code base, and even if you decide to remove it later, there may be fallout from that decision forever.

I also feel like the reason for dropping the CIV code base every so often and starting fresh is just so that this kind of cruft can be avoided. Save game compatibility would mean that each release would become progressively more difficult as more and more code would have to be customized to deal with long gone or obsolete patches.

To be blunt, I don't think save game compatibility is worth it, and I won't be writing the code to do it.

Ammler wrote: I think, the CIV would be worth to have a wiki page: http://wiki.openttd.org/index.php/CIV

I'm not against there being a Wiki page, but I am weary of promising something that would create more work. I'm happy if someone else wants to do it, but I worry that without regular work it become stale. My other concern is that I feel that the Wiki is a little more official than this project. I don't want the core developers to feel like we are impinging on there territory. Honestly I'd rather wait for an invitation to use project resources like the wiki and possibly version control. However all this is personal opinion, so don't let that stop you from doing it if you are so inclined.