New Release Plan

[SinbadEV]

we

Who are you and what have you done for spring?

What he appears to be doing is trying to recommend changes to the current system. Not everyone is a developer/modder/etc.
Unless you mean to suggest that no-one with X years of modding/developing/posting with Spring may try to make suggestions.

I think Regret was calling into question el-matarife's use of the word "we" insinuating that he was part of the development team or similar. Misunderstandings and hurt feelings are common in any type of communication and doubly so in forums.

On the other thing you said, I agree that it would be pretty cool if there was some kind of system in place for reporting bugs for all the disparate projects involved... up till now this has been dealt with by simply expecting each project to deal with their own stuff.

It would be pretty cool if we added some more projects to the mantis, one for "Widgets", one for "Maps", and then one for each of the Mods that choose to become involved with the initiative... then if a bug was submitted to the Mantis as a engine-bug and was determined in testing to be a Mod bug you could reassign its project instead of rejecting it... If the Mod, Map and Widget Makers were keeping tabs on this process it would help them track and resolve bugs better as well.

[zwzsg]

What he appears to be doing is trying to recommend changes to the current system. Not everyone is a developer/modder/etc.
Unless you mean to suggest that no-one with X years of modding/developing/posting with Spring may try to make suggestions.

If you're not a developper/modder/poster/etc... you can't pose as one, which is what the "we" does. You can still make suggestion, just don't make it sound like you're part of the people who will do it / have done it in the past, when you're clearly not.

[Tobi]

There's one big problem with reporting bugs in Spring, at least for someone who doesn't know it well - You have to know what part of the overall "project" the bug is in. Is it a widget bug? Maybe a mod bug? What about one in the map itself? Maybe it's in the engine itself and thus actually a Spring bug. How about in the lobby?

That's FIVE PLACES where the bug may reside, and each of them requires being reported in a different place/forum/board if you don't want to be missed/ignored.
Knowing this and being able to discern which of those components the bug is in is rather a sizeable hurdle that most other projects don't have.
I've done some bug reporting on other OS projects in the past, but in all those other projects it's a case of me turning up, listing my bugs and them going "yep, these ones are actual bugs, we'll get right on them".

Very true yeah.

I wouldn't know a solution which I think would work in practice though.

For now the best advice I can give is to just write this high quality bug report and submit it at the project where you think it belongs.

Good chance if it's an otherwise high quality bug report, only filed in the wrong bug tracker, it will eventually get reposted in the right bug tracker, or you will be told what the right tracker is, so you can post it there yourself.

[YokoZar]

What he appears to be doing is trying to recommend changes to the current system. Not everyone is a developer/modder/etc.
Unless you mean to suggest that no-one with X years of modding/developing/posting with Spring may try to make suggestions.

If you're not a developper/modder/poster/etc... you can't pose as one, which is what the "we" does. You can still make suggestion, just don't make it sound like you're part of the people who will do it / have done it in the past, when you're clearly not.

El_Matarife is a user and that makes him a part of this community. The use of the collective we is entirely appropriate.

We all have an interest in improving Spring. It's to none of our benefit to become poisonous people and distract the project with useless politics, name-calling, or challenges of experience. Whether someone's an open source development expert or a clueless micromanager doesn't matter - this thread has already generated several real suggestions for improvement and volunteers offering to implement them.

I can't promise anything on behalf of the others, but for my part I'm going to try and listen.

[YokoZar]

There's one big problem with reporting bugs in Spring, at least for someone who doesn't know it well - You have to know what part of the overall "project" the bug is in. Is it a widget bug? Maybe a mod bug? What about one in the map itself? Maybe it's in the engine itself and thus actually a Spring bug. How about in the lobby?

That's FIVE PLACES where the bug may reside, and each of them requires being reported in a different place/forum/board if you don't want to be missed/ignored.
Knowing this and being able to discern which of those components the bug is in is rather a sizeable hurdle that most other projects don't have.
I've done some bug reporting on other OS projects in the past, but in all those other projects it's a case of me turning up, listing my bugs and them going "yep, these ones are actual bugs, we'll get right on them".

Very true yeah.

I wouldn't know a solution which I think would work in practice though.

For now the best advice I can give is to just write this high quality bug report and submit it at the project where you think it belongs.

Good chance if it's an otherwise high quality bug report, only filed in the wrong bug tracker, it will eventually get reposted in the right bug tracker, or you will be told what the right tracker is, so you can post it there yourself.

It would be nice if we could just move bugs between the different trackers easily. That requires using a common tracking interface between them though (eg Launchpad).

Alternatively, we could just change our own behavior and make sure the poster of a report is told the proper place to post it when it's rejected ("closing invalid -- please report this as a bug in the mod forum (link) rather than in the Spring engine")

[koshi]

Anyone who wants to use SpringLobby's redmine for his issuetracking, wiki or forums needs is welcome. Just register and contact me with the project's name.

Mantis and Trac DB import is also a possibility.

[Licho]

Btw imo main problem with lack of testing is that you cannot playtest on same server. Test/stable scheme CA is using works well and i would like to implement something similar for engine.

I plan to support at least multiple executable versions in winter, possibly even whole spring installs. I will have to hack engine version to game name or even to modoptions, but its still doable :)

[el_matarife]

Making installing a test version as easy as extracting a zip file with a binary and a few DLLs would go a long way to making testing easier, as well as patching. Imagine (on Windows) having /Spring/Binaries and /Spring/Binaries/Dlls where all of Spring's important files could go, making patching and installing easy, along with supporting multiple versions side by side. It would make it really easy for the lobby clients to implement automatic Spring patching and test version downloading.

[Licho]

Are you joking matarife? THERE IS AND WAS FULL INSTALLER FOR TEST VERSIONS.

It is and was easy! Easier than you suggest.

[flame]
Its laziness of people that is problem, tbh you should stop posting useless crap and start actually doing something usefull.

You can start with wiki if you want.
[/flame]

Making posts wont change anything. People here wont do what you or anyone else wants them to do. They will only do what they want to do.
You could perhaps convince some to join you if you were well known respected developer and started work yourself. But you are neither and dont appear to be working on something important.

[tizbac]

The problem as licho said, is that nobody tests except devs and in singleplayer mostly, i'm hosting the test server, but nobody in last 20 days logged in, so it's just that people does not want to test, and installing 2 versions is very easy atm.
Adding support for multiple versions on main server is easy, but requires protocol changes , the best way would be adding another field to openbattle command & battleopened.
The problem about the testing isn't that, i think it's because maybe half of the player doesn't know that spring is opensource and more than 3/4 doesn't know how to debug/compile

[Licho]

I want to support it even without protocol change. There is plenty of places where i can sneak engine version data..
And winter works without unitsync, it manages content itself so its easier than in traditional lobby.

[aegis]

upcoming protocol changes will be handled by the lobby client and server advertising their capabilities.
a lobby which doesn't advertise its changes will be automatically supported with legacy code.

specifics are negotiable.

[Peet]

upcoming protocol changes will be handled by the lobby client and server advertising their capabilities.
a lobby which doesn't advertise its changes will be automatically supported with legacy code.

specifics are negotiable.

Assuming you actually make a stable release:

THANK YOU

[Auswaschbar]

The problem as licho said, is that nobody tests except devs and in singleplayer mostly, i'm hosting the test server, but nobody in last 20 days logged in, so it's just that people does not want to test, and installing 2 versions is very easy atm.
Adding support for multiple versions on main server is easy, but requires protocol changes , the best way would be adding another field to openbattle command & battleopened.
The problem about the testing isn't that, i think it's because maybe half of the player doesn't know that spring is opensource and more than 3/4 doesn't know how to debug/compile

That is because we were having test games on the main server.

[Neddie]

I wish somebody had consulted me on this before the thread started. I brought this sort of stuff up several times over the past few years.

[el_matarife]

Are you joking matarife? THERE IS AND WAS FULL INSTALLER FOR TEST VERSIONS.

It is and was easy! Easier than you suggest.

I know there's a full installer but that's actually worse than just having a zip file. The installer takes a minute or two to run and because it specifically is designed to do a "full install" of Spring it really needs its own directory. It also leaves files all over the place, even after an uninstall. A zip file with just Spring's EXE file plus any changed DLLs would be the right way to go here, since deployment could be automated by the lobbies.

[zwzsg]

There is also an zip file of just the exe. Join #buildserv on the lobby, check topic.

[Licho]

A zip file with just Spring's EXE file plus any changed DLLs would be the right way to go here, since deployment could be automated by the lobbies.

Could be automated??
Yes it could, if someone actually codes it. It has nothing to do with getting right files, its not a problem.. As zwsg says..

Feel free to modify tasclient or springlobby or qtlobby or winter or sefilobby to support this.
*edit damn forgot battle hub! That too

[Forboding Angel]

Look I dunno if this will help, but I'm attempting to at least garner a little bit of interest. THere are a lot of people around who follow evo's development but never say anything or make themselves known, so maybe some of those people will come out and help us a bit: http://springrts.com/phpbb/viewtopic.php?f=51&t=19895

[jeykey]

El_Matarife is a user and that makes him a part of this community. The use of the collective we is entirely appropriate.

We all have an interest in improving Spring. It's to none of our benefit to become poisonous people and distract the project with useless politics, name-calling, or challenges of experience. Whether someone's an open source development expert or a clueless micromanager doesn't matter - this thread has already generated several real suggestions for improvement and volunteers offering to implement them.

I can't promise anything on behalf of the others, but for my part I'm going to try and listen.

+1