Code Management: Quo vadis?

Topic: Code Management: Quo vadis? (Read 14425 times) previous topic - next topic

Code Management: Quo vadis?

January 24, 2009, 07:54:19 pm

These days, with my time getting scare, I am wondering if I am still the right person. In the last six weeks, half of my time was devoted to work with other people's code. This is very close to what I consider work and not something I want to do in my two hours before sleep.

Patches have become plenty, but only very few people actually tested them, as it seems, and nearly non of them recieved comments. Also I refused some of them for various reasons. Thus, I am asking me the question, if I am still the right person to lead the project (as position I gained only by accident anyhow). I have become quite conservative on what things to include, mainly because the program is already quite mature in my opinion. (But Hajo though the same just before he quit.)

Also the things I asked for contributions, like better AIs or networking recieved very little attendtions. Even though coding AIs would be possible without changing the main code.

This gives me the impression that I am not the right person to lead at least alone. However, and here is the problem, I am not sure who could replace me. The only persons that could do this are either kierongreen (as he knows the code very well) or VS (who has the ideal combination, knows the code and did/does maintain a pak) or z9999. All other possible candidates are not with the projects long enough I feel, although some are looking promising.

As to bring the stuff missing (AI settings, difficulty dialoge, networking) into order, plus some important patches (internal routing, powerline tunnels, underground mode) I think I will not include anything for a while that is not mentioned that changes the game core. This means I will not test patches, since I have absolutely no time left for that, and will spend only short infrequent time on the forum.

Maybe things will improve in the next weeks to month. I surely hope thy would.

Re: Code Management: Quo vadis?

Reply #1 – January 24, 2009, 11:11:00 pm

I am definitely not suited for work on the code. So far all my patches broke more than improved. Also, I have my pak128 and that is sometimes enough to pull my hair out or wake in night, covered in sweat

To me it seems we are still building our coding community. But community is what open source is about! We have a fairly good number of wizards good with makeobj and capable of turning graphics into game objects. We have a reasonable number of people capable of making said graphics (we want more!). But we have pitifully few coders accepted into the "inner circle", and of these, most are inactive. As a result, the only active programmer is swamped with all kinds of work.

I think that getting patches is a good start. But once it is clear that we have people interested in the project and capable of doing good work alone, let's go further. Expanding the core team somehow from these people should be the road to future.

I know that this is all nice theory but getting it to work is harder. Well, let's hope... once the bump in road is overcome, it should be better.

Re: Code Management: Quo vadis?

Reply #2 – January 24, 2009, 11:34:11 pm

Completly agree with VS. I thinking all veteran members have realized that nowdays the way Simutrans code is developed has changed. There's a some people doing a lot of small patches, as you said must be tested. Some of those small mods only can be tested by experienced players with some coding skills (you need to compile from source), so that's another problem.

Therefore, I think is a great idea to join more people to the development team. Not just coding, but also maintaining what they program. Prissi, You sometimes have "complained" that you feel lonely coding, and now that kierogreen it often out, it's a good ocasion to gather the people interested in coding atm, divide the code related tasks and renew the development team. The amount of patches shows that there's people still interested so why not to join people to what have considered since a few years ago, is the weakest part of the project? Divide and conquer, in addition you'll have more time to play with your baby..

Re: Code Management: Quo vadis?

Reply #3 – January 25, 2009, 04:53:38 am

Having some accepted but heavily reworked/upgraded patch (overtaking fun patch, thanks prissi), rejected (QoS p****enger), waiting in unknown state (avoid overcrowding), proposed by someone else and accepted (links to line information window), proposed by me but with little interest by forum members (multiplayer graphics), and in progress (convoi replacement tool), all of them in my luggage, I have to say that I'm happy in general with prissi's way of carrying out things.

That doesn't mean that I agree with all his decisions or that I would decide the same, more on the contrary, but who am I to question things with you people being here for such a long time? Dedication and the present state of the program should count, shouldn't it? I can come here with a bunch of new ideas, do a revolution, make some people quit, and then, disappear myself when I get bored. Would that be logical?

What I don't share with prissi is his view about open software development. Nobody is paid here. So, it is not a question of "here we have these two propositions", I want people to work on this. Nor it is a question of "democracy". Let's vote what has to be done, and once voted, people must work on that. 80% of us can vote that pak96.comic should have a sausage factory chain. Now, you, pak96.comic developers, start working on that. That makes no sense.

But that same argument applies to prissi himself, as he clearly states above. Should he work in something he doesn't believe in? That would be a job... Certainly not! Should he spend long hours arguing about if this is realistic, if this is more fun, if this is logical... no way... If someone spends his time and hard dedication, one would like some power of decision...

What is the key of open software then? Forking, in my opinion. If some people have a lot of good ideas, just fork, maintain that and let people compare results. That is what has made paks so successful. Paks has "forking" process built inside. We have not one but many parallel paks.

Me, as a "casual" developer here would like some clearer foresight. Some "as-you-say-above" small patches require a big amount of time first to devise how things work and then to develop. Before embarking in such a journey, it would be very nice to know if that will by no means come to trunk, has little chance, or more to do so. Then one can decide if the effort required is worth or not. That is not trivial. Since all of us are players as well as developers. If a patch is not included, you have to decide: either to freeze and work with your nice feature and lose other improvements or the other way around.

I find my tête-à-tête with James Petts about the upgrading/replacing vehicle tool very instructive in this respect. First, because nobody, at least in the common people forum, spoke there (no interest?, opposition?, ...) and second because he had a view on the subject and I had another. In a job, I will do whatever for the money, but in open software I have to be very convinced about something to spend my scarce time on it. There must be a quid pro quo. And "quo" is not money here. What else then? That's the problem and the marvelous thing at the same time.

In summary (the opinion of somebody not too old here and, who knows, that can disappear any time):

Keep code development as it is now
Fork and support as many times as wanted (James had here an excellent idea)
Open more some side parts: a writable code wiki, for example, more in the wiki spirit
Open several more or less official medium-sized projects and wait for people to join, but don't discourage if that is not so
Have clear rules and early decisions about what jobs would be a lose of time and would be a coding p****time for developers, whatever those rules may be

Re: Code Management: Quo vadis?

Reply #4 – January 25, 2009, 09:40:37 am

I really cannot be the maintainer. I've too much simutrans projects as it is for my spare time without anymore being added. That said I'll continue to develop patches when I can.

I have to also say that recently I've felt that a lot of the patches seem unnecessary (to me). That's not to say I don't appreciate the amount of work that people have put into them, or that they may feel the need for the changes - just that I don't.

Anyway, I'm sorry I can't contribute as much as I used to, or in some ways even want to. How prissi manages to do as much as he does astonishes me and he rightly deserves the praise he gets for it.

Re: Code Management: Quo vadis?

Reply #5 – January 25, 2009, 11:07:23 am

Isidoro,

very interesting post! What you suggest is indeed a good idea. I might well take the opportunity at some stage to set out the aims of the Simutrans-Experimental project in a similar fashion. (In brief, the principal idea of the Experimental version is to produce a version of Simutrans with a number of refinements to the economic aspects of gameplay both to make the game more enjoyable (and the challenge more consistent throughout, instead of being very hard at the beginning and very easy later on) and to make it closer to reality).

Incidentally, your avoiding overcrowding patch has already been incorporated into the Experimental branch, and, once I have reworked the revenue system, I hope to incorporate the QoS, too (albeit quite probably with modifications to work with that new revenue system and the private cars feature); likewise with the convoy replacement tool, but again, likely with modifications to incorporate refurbishing.

I very much appreciate your work on Simutrans - I do hope to see you keep it up. I shall look forward to more patches from you in the future :-)

Re: Code Management: Quo vadis?

Reply #6 – January 25, 2009, 11:34:59 am

The avoid overcroding patch has a chance to go into trunk, since it just expands the current system a little further without breaking anything else.

And I would really like to give rules to what things are good and what not, but I honestly cannot. First because I have no idea what you will come up with. And there is a todo list of stuff to be done, but this seems to be ignored. As you said, this would be probably work. But in general, if not like five people comment about it, then it is probably only a must have for the patcher.

Integrating a patch is work for me, since usually I read the code to spot errors add comments and the like. I mean, I could just patch a leave it, but then sooner or later the code would losse integrety, which is not the style I would like to do it.

I would like to have more core developer. But the only one long here enough and producing good compatible code are kierongreen and z9999. I would offer them write access any time ... as isidoro said, until I can be sure he is not a one month time I would like him to wait a little longer to get a feeling on what simutrans is more or less feeled to be about around here or get involved in a pak set development. That is why I said that things might improve.

On patches. OpenTTD have BuildOpenTTD, a net application that can use mingw nearly automatically to apply one patch and compile. I will look into it, it might be possible to have something like that for SImutrans too.

Re: Code Management: Quo vadis?

Reply #7 – January 25, 2009, 11:56:27 am

Quote

Have clear rules and early decisions about what jobs would be a lose of time and would be a coding p****time for developers, whatever those rules may be

Seconded. There was some list of rejected ideas, perhaps it's time to update it - or simply bring to attention. I can't find it but here is at least some food for thought. If nothing, it at least can serve to show what kind of ideas were deemed bad at that time.
http://archive.forum.simutrans.com/board/00058.0/index.html

Also the opposite, wanted things, should be somewhere... and they are, we just ignore them

Including people in the core team should not happen hastily of course

But I mentioned because currently it is (imo) the main problem. We'll see.

Re: Code Management: Quo vadis?

Reply #8 – January 25, 2009, 12:00:27 pm

As long as you have interest in simutrans, current simutrans is your project, prissi.
If someone feel simutrans is not fun, he can make a new project. We can't stop him because simutrans is an open source project.

But project is a different story, it always needs to make a choice.

Quote

Also I refused some of them for various reasons.

I think you did a very clever choice. Even if I was you, I did the same way.
If you accepted all patches without choice, I would leave this project.

As for me, I made some patches but they are add-ons.
I made them, because I wanted to made them and I wanted to share them.
It is equivalent to vilvoh making many add-ons for pak64 and sharing them.
So, If you don't want to include it in trunk, you don't need to test nor comment to it.

Quote

And there is a todo list of stuff to be done, but this seems to be ignored.

I avoided them by design, because I thought you have a plan for them.

Re: Code Management: Quo vadis?

Reply #9 – January 25, 2009, 01:07:11 pm

Sorry. I'm not a programmer, but one thing.

Precisely because i'm not a programmer I would find it nice. When every patch-developer make a (f.e.) simutrans-patch.exe. Than can test the patches the none-programmes and make bug-reports.

And only if the patch-tester say, this is a good patch, then we should give it to prissi. So, in the best case he have only to have a look over it. I hope so.

Re: Code Management: Quo vadis?

Reply #10 – January 25, 2009, 01:14:41 pm

well, I'm not very in the loop about programming simutrans. But I've got experience in other open source projects. And I've noticed that simutrans programming is somehow a bit different compared to other open source projects. For example at a big project, milestones are made. There's a discussion on each an every major or minor milestone. And then a list with things, that need to be done for this milestone is made up. And only the improvements that are mentioned on this list will be discussed for this milestone, and only on these the programmers will work.
In simutrans I've never seen such things / lists. I think this would be a very great deal, because patch-makers will have certain goals to work on. An prissi has principles (the points on the list) to decide which patch is tested and included in the trunk.

Re: Code Management: Quo vadis?

Reply #11 – January 25, 2009, 01:16:27 pm

Sojo,

have you looked at Simutrans-Experimental? One of the main purposes of that branch is exactly as you suggest :-)

Re: Code Management: Quo vadis?

Reply #12 – January 25, 2009, 03:40:31 pm

Quote from: jamespetts – on January 25, 2009, 01:16:27 pm

Sojo,

have you looked at Simutrans-Experimental? One of the main purposes of that branch is exactly as you suggest :-)

Of course. But this are only your patches. Should every patch-maker to this?

Re: Code Management: Quo vadis?

Reply #13 – January 25, 2009, 03:43:41 pm

That's what you're suggesting, I think - but I do incorporate other people's patches into Experimental, too: there is currently the crowding patch by Isidoro, and the silent vehicles in fast forward mode patch by VS; I am hoping to put the underground view and rivers patches in, too, when they are a little more polished.

Re: Code Management: Quo vadis?

Reply #14 – January 25, 2009, 05:41:17 pm

Quote from: sojo – on January 25, 2009, 01:07:11 pm

Precisely because i'm not a programmer I would find it nice. When every patch-developer make a (f.e.) simutrans-patch.exe. Than can test the patches the none-programmes and make bug-reports.

I think, this could be wernieman's job. Maybe he can implement an interface like in BuildOpenTTD on the nightly page? This should be secured by a p****word and if a developer thinks, that a patch is worth it, he can upload it and the binaries will be created.

Re: Code Management: Quo vadis?

Reply #15 – January 25, 2009, 07:29:15 pm

Having specific binaries is only useful for patches that make significant changes, I think - small enhancements and bugfixes that will either make it to the trunk or have a reason not related to gameplay style preferences why they will not will not really benefit from testing in this way.

Re: Code Management: Quo vadis?

Reply #16 – January 25, 2009, 07:36:15 pm

I wasn't a fan of branching, because i'm afraid of cross compatibility (paks and savegames working with the different branches) but now i can see the point.

What i suggest is to let the main trunk for bugfixing and gui patches, to get a completely stable release. I think that for many aspects, it's a very mature product, although i bend for the experimental line.
Experimental ST could run for a more innovative approach, benefitting of the improvement of the main trunk.

Re: Code Management: Quo vadis?

Reply #17 – January 25, 2009, 07:38:51 pm

Quote from: prissi – on January 25, 2009, 11:34:59 am

[...]
And I would really like to give rules to what things are good and what not, but I honestly cannot. First because I have no idea what you will come up with.
[...]

You are right here. Sometimes patches are posted with no previous notice. Or one doesn't know what will come at the end or the quality of the final product...

Quote from: blitzmaster – on January 25, 2009, 01:14:41 pm

[...] For example at a big project, milestones are made. There's a discussion on each an every major or minor milestone. And then a list with things, that need to be done for this milestone is made up.
[...]

That's a very nice point from the developers point of view. So, one can "safely" join the projects one likes. But the main point remains. Who is to decide those milestones? And, if after discussing, we arrive to some of them and the project leader(s) is/are against them, should (t)he(y) work for it? My answer is clear: not at all.

Quote from: jamespetts – on January 25, 2009, 11:07:23 am

[...] very interesting post!
[...]likewise with the convoy replacement tool, but again, likely with modifications to incorporate refurbishing.

I very much appreciate your work on Simutrans - I do hope to see you keep it up. I shall look forward to more patches from you in the future :-)

Thanks, James. The convoy replacement tool is much harder than I thought. When I have the first step, I'll open a thread for all of you to follow/comment on. But it will take time... In this very patch, I'm conscious that it is very difficult for it to go into trunk (for comments about similar tools elsewhere in the forums) but I don't mind. But the good thing is that I know in advance...

Quote from: z9999 – on January 25, 2009, 12:00:27 pm

As long as you have interest in simutrans, current simutrans is your project, prissi.
If someone feel simutrans is not fun, he can make a new project. We can't stop him because simutrans is an open source project.
[...]

Should we stop him, z9999, if we could? I hope you don't mean that, for the sake of free software.

I completely agree with the first sentence, though.

Re: Code Management: Quo vadis?

Reply #18 – January 25, 2009, 08:09:12 pm

I think there is a misunderstanding in z9999 comment.

But back on topic: I consider also overcroded stations avoidance, but honestly I cannot find the patches. I would be nice and would help a lot, if patch would at leat posted in patches ...

And someone taking care of finished stuff moving to finished and so on would help too.

Re: Code Management: Quo vadis?

Reply #19 – January 25, 2009, 09:16:26 pm

At the moment no, because the "Building Server" is not quick!

And I don't whant, that somebody have direkt access to the building Server (O.K. there is an ssh acess, but .... I hope you understand)

The Problem is the design of the system, it is not security for the direkt acess.

(Sorry for my english ;o) )

I think about a new system but
1. Money
2. Money
3. Time

and the Server is not only for the nightlys. He is my mailserver, storage etc.
When we will implement a system like the ottd, then we need a only server for this! (And money per month)
Then it will not good, when the server is "at home"

Re: Code Management: Quo vadis?

Reply #20 – January 26, 2009, 02:31:31 am

What about a link to a web disk like mediafire? Life span of such nightlies wouldn't be long.

@prissi: The patch is very short but the old version conflicted with gib_/get_, different capacities for p****, mail and goods and new random offset to choose packets in the station. Here's an updated version.

Re: Code Management: Quo vadis?

Reply #21 – January 26, 2009, 09:38:13 am

Angband, a very old open source game, at some point split into several dozen variants. Each with their own "pak sets" (in case of Angband that is theme and monster list) and slightly changed game features.

It didn't really harm Angband I think, but it might be more difficult for players to choose. Nowadays they have "vanilla Angband" which is a conservative line that keeps the history and more than two dozens of sometimes quite different variants.

If Simutrans is now at such a point, where it'll split into a conservative line, which is developed slowly and only will incorporate very few patches, and one or more variants, that all get their own gameplay, it is alright with me.