The way to get things done is by doing them, not by writing the umpteen-billionth mile-long post on how everything should be in the ideal fantasy world. You use the pronoun "we" many times, as in "we should fix all bugs and make every release perfect!" and "look at all the defects we've willingly ignored!", but what have you ever done for Spring or any of its related projects? Do you have any idea how much time and energy can be involved in fixing something like the ground-decals bug? I'm going to be blunt and say put your e-money where your e-mouth is. (Yes, the whole Spring release process could be improved etc., but that's not what concerns me here. Also the fact that you're ignoring the reality of the situation [not nearly enough testers, angry mobs when new versions are pushed out too rapidly after one another, angry mobs when new versions are pushed out too infrequently, ...] is annoying.)el_matarife wrote:Please don't take this thread as an attack, I know I worded it aggressively but it seems like that's the only way to get stuff done around here sometimes.
New Release Plan
Moderator: Moderators
Re: New Release Plan
Last edited by Kloot on 24 Jul 2009, 14:13, edited 1 time in total.
-
- Posts: 933
- Joined: 27 Feb 2006, 02:04
Re: New Release Plan
I'm using "we" so I don't sound like a jerk who's going around blaming people for problems. If you want to launch ad hominem attacks against me for "not doing my fair share" or "living in a fantasy world" go ahead, it just proves that you've got nothing to say about the release process fixes I'm proposing.Kloot wrote:The way to get things done is by doing them, not by writing the umpteen-billionth mile-long post on how everything should be in the ideal fantasy world. You use the pronoun "we" many times, as in "we should fix all bugs and make every release perfect!" and "look at all the defects we've willingly ignored!", but what have you ever done for Spring or any of its related projects? Do you have any idea how much time and energy can be involved in fixing something like the ground-decals bug? I'm going to be blunt and say put your e-money where your e-mouth is. (Yes, the whole Spring release process could be improved etc., but that's not what concerns me here.)
Trust me, I hate to write these huge walls of text as much or more than you hate reading them, but we keep having the same issues with the same solutions proposed but never implemented. Most of the stuff I'm talking abut has been adopted with great success at other projects so don't you ever wonder why we're still doing things our own unique dysfunctional way?
Re: New Release Plan
I can provide auto generated test builds for openSUSE 11.1 .
Earlier versions are harder to do due new Boost version requirement.
I would need to check in a new Boost version...
Also other distributions are possible with the openSUSE build service.
RPM distributions:
openSUSE Factory
openSUSE 10.3, 11.0, 11.1
SLES/SLED 10,11
SLES 9
Mandriva 2008, 2009
Fedora 10, 11
RHEL 4,5
CentOS 5
DEB distributions:
Debian 4,5
xUbuntu 6.06, 8.04, 8.10, 9.04,
(I hope I sorted the distributions right :S )
But be aware deb packages are pain to make, I will not make them.
Other rpm packages besides openSUSE require more work than openSUSE because of missing dependencies, mostly due new boost.
Side note: Live CDs with Spring based on KIWI are possible, too.
Earlier versions are harder to do due new Boost version requirement.
I would need to check in a new Boost version...
Also other distributions are possible with the openSUSE build service.
RPM distributions:
openSUSE Factory
openSUSE 10.3, 11.0, 11.1
SLES/SLED 10,11
SLES 9
Mandriva 2008, 2009
Fedora 10, 11
RHEL 4,5
CentOS 5
DEB distributions:
Debian 4,5
xUbuntu 6.06, 8.04, 8.10, 9.04,
(I hope I sorted the distributions right :S )
But be aware deb packages are pain to make, I will not make them.
Other rpm packages besides openSUSE require more work than openSUSE because of missing dependencies, mostly due new boost.
Side note: Live CDs with Spring based on KIWI are possible, too.
Re: New Release Plan
Didn't you mean "But be aware deb packages are pain to make on openSUSE buildservice" ?
Imo forget about trying for one-for-all builds on that, i've tried for SL and their implementation simply is mostly dysfunctional (not that that is surprising ofc, there's little benefit for them in it, is there? )
Imo forget about trying for one-for-all builds on that, i've tried for SL and their implementation simply is mostly dysfunctional (not that that is surprising ofc, there's little benefit for them in it, is there? )
Re: New Release Plan
The main thing I have to say about your proposed release process fixes is that they completely ignore Spring's lack of testers. It would be one thing if, say, all the 8v8 BA-DSD guys were to participate in your playtesting schedules, but such mass-tests have been tried / organized before and they didn't. IIRC the peak was ~20 people for the 76b1 pre-release, which was "known to be coming" around that time. That leaves testing to whom, exactly?el_matarife wrote: I'm using "we" so I don't sound like a jerk who's going around blaming people for problems. If you want to launch ad hominem attacks against me for "not doing my fair share" or "living in a fantasy world" go ahead, it just proves that you've got nothing to say about the release process fixes I'm proposing.
You are comparing Spring to projects that have hundreds, if not _thousands_ of regular contributors and testers. There is a difference of scale that no new release process will compensate for.el_matarife wrote: Trust me, I hate to write these huge walls of text as much or more than you hate reading them, but we keep having the same issues with the same solutions proposed but never implemented. Most of the stuff I'm talking abut has been adopted with great success at other projects so don't you ever wonder why we're still doing things our own unique dysfunctional way?
Last edited by Kloot on 24 Jul 2009, 14:34, edited 1 time in total.
Re: New Release Plan
Yeah, making deb packages in openSUSE buildservice is a pain.
I dont know how it is general or in other buildservices...
Their main focus is of course on their distribution.
So it is useful for rpm packages but not for debian packages.
Maybe someone knows a better buildservice?
I dont know how it is general or in other buildservices...
Their main focus is of course on their distribution.
So it is useful for rpm packages but not for debian packages.
Maybe someone knows a better buildservice?
Re: New Release Plan
spring compiles with boost 1.34 again as of last week. This is the so so so so VERY old version as Auswaschbar always puts it . It is the default version in Ubuntu 8.04 LTS, so i guess it should work for a lot of non recent other distros too.
Re: New Release Plan
Launchpad for buntu, but that's it. Fedora has some service I think, but neither was it accessible to just anyone nor can I seem to find it again.
-
- Posts: 933
- Joined: 27 Feb 2006, 02:04
Re: New Release Plan
You're right, we do have a problem getting enough testers. Some of it is due to technical difficulties around installing a second copy of Spring to test, and some of it is a scheduling problem. It would certainly be nice if it was easier and more convenient to do Spring testing, but I think what would help the most is people knowing there's going to be enough testers there to get some work done. No one wants to sit around waiting to get a test game started on an empty lobby. We either need a big enough dedicated core of testers to show up every time, or a good set schedule. I'm open to other ideas as well, I'm not entirely sure what the best way is to motivate people to show.Kloot wrote:The main thing I have to say about your proposed release process fixes is that they completely ignore Spring's lack of testers.
Re: New Release Plan
Who are you and what have you done for spring?el_matarife wrote:we
Re: New Release Plan
For testing IMO we need some non-developer person who has some clue about software development and how to find / report bugs who organizes testing games regularly.
This guy can then
Hence why I say now, someone who does not develop Spring must do it, or at least someone who enjoys pulling people into a game one by one and playing first line helpdesk for a number of hours per week
IMO only once this testing is set up properly it makes sense to think about planning releases. Now finding bugs is just too random and happens way to close to release, so any plan/ETA is horribly inaccurate.
Also we could use more people triaging bugs. (confirming them, ordering them, adding steps on how to reproduce, attaching small test mods/maps/widgets/programs, going after reporters to give more information, etc.)
This guy can then
- do some manual single player testing first to pick a commit to test that is not completely broken,
- spam lobby to lure people into testing new Spring,
- help people setting up test release,
- tell people what things to test specifically (ie. what changed since the previous test session),
- make notes of all bugs (because in my experience in test games people just say the bugs in ingame chat and do not actually report them),
- and after the games work out the bugs properly, including steps on how to reproduce them (also by interviewing the player who reported it a bit more), combining related bugs, translating stacktraces, etc.
- and finally submit these high quality bug reports to mantis
Hence why I say now, someone who does not develop Spring must do it, or at least someone who enjoys pulling people into a game one by one and playing first line helpdesk for a number of hours per week
IMO only once this testing is set up properly it makes sense to think about planning releases. Now finding bugs is just too random and happens way to close to release, so any plan/ETA is horribly inaccurate.
Also we could use more people triaging bugs. (confirming them, ordering them, adding steps on how to reproduce, attaching small test mods/maps/widgets/programs, going after reporters to give more information, etc.)
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: New Release Plan
Well, at least you could have informed yourself how the spring release process works before giving suggestions on how to fix it.el_matarife wrote:I'm using "we" so I don't sound like a jerk who's going around blaming people for problems. If you want to launch ad hominem attacks against me for "not doing my fair share" or "living in a fantasy world" go ahead, it just proves that you've got nothing to say about the release process fixes I'm proposing.
Trust me, I hate to write these huge walls of text as much or more than you hate reading them, but we keep having the same issues with the same solutions proposed but never implemented. Most of the stuff I'm talking abut has been adopted with great success at other projects so don't you ever wonder why we're still doing things our own unique dysfunctional way?
Re: New Release Plan
One way to get mod/game dev people to help with testing is to poke them about cool stuff that's in the next build - this is where the occasional post from whoever just did/fixed something cool would probably help a bit. I know you guys aren't a huge fan of e-fame, and I know modders can just stay up to date by reading commit logs, but it might be a help.
For example, tobi just posted on the S44 forums about how kloot added backwards movement. My thought process on reading that was: "Holy shit! I want to use backward movement on my tanks! I want to test it right away!"
So now I'll be doing my best to get people to test S44 with a recent build, because I want to see how backwards movement plays into the game.
For example, tobi just posted on the S44 forums about how kloot added backwards movement. My thought process on reading that was: "Holy shit! I want to use backward movement on my tanks! I want to test it right away!"
So now I'll be doing my best to get people to test S44 with a recent build, because I want to see how backwards movement plays into the game.
Re: New Release Plan
Heh, mission accomplished
This indeed works whenever there is a (big) new feature, but one should remember there also should be testing when there have only been big refactorings - probably the same or higher chance it breaks stuff, while nothing cool will have been added.
That's why I think regular (ie. weekly) testing games are important. And yeah, if there has been a new feature, it may make it easier to lure people into participating
This indeed works whenever there is a (big) new feature, but one should remember there also should be testing when there have only been big refactorings - probably the same or higher chance it breaks stuff, while nothing cool will have been added.
That's why I think regular (ie. weekly) testing games are important. And yeah, if there has been a new feature, it may make it easier to lure people into participating
Re: New Release Plan
ok let me advertise a new feature: units can move backwards with if you add a single tag. test gogogo
Re: New Release Plan
Here's a crazy idea.
1. Make Spring auto-update itself on startup.
2. Features that break large sections of source must be tested and shown to be reasonably stable before release. If developers are working on something... you guys all know that I and a few others are willing to test these things and attempt to verify they're working.
3. If you want QA testing to become more effective, you have to let people know what they're expected to test, and how to go about it. Part of this problem, at least for me, is that since we went to Git from WebSVN, I can't review the commits in depth any more- it only shows the last few.
But when something's out there and a developer wants it tested, just give a holler, saying "hey, I did this, it's supposed to do this, this is how to test it", and I for one will take a look, so long as it's not stuff that I can't run (which applies to the multi-core code and any GLSL my GPU can't handle).
I've done this process with many of you (core developers) over the years via PM, but I see no reason why this wouldn't work even better in public, especially as I, like anybody else, may suddenly disappear. Better to have a public process for such things.
Maybe put new stuff into a news feed, like ModelBase, where major new features can be submitted for testing and comments?
I would rather see more frequent releases and bug-fixes in a scenario where updates are also more frequent, basically. Not knowing whether the release date on a given feature is weeks or months away is very aggravating as a game developer- it's like putting down money on a roulette wheel. It'd be one thing, if I knew that Feature A was still rough and not available, but that Features BCDE were all on-track for release in the next update... but as things stand, I frequently have to bet on when ABCDE will be available, because it's all-or-nothing, even if BCDE are minor.
The only stopping-point is having an auto-updater for the engine. Can Det's work on the SpringDownloader be used for these purposes?
1. Make Spring auto-update itself on startup.
2. Features that break large sections of source must be tested and shown to be reasonably stable before release. If developers are working on something... you guys all know that I and a few others are willing to test these things and attempt to verify they're working.
3. If you want QA testing to become more effective, you have to let people know what they're expected to test, and how to go about it. Part of this problem, at least for me, is that since we went to Git from WebSVN, I can't review the commits in depth any more- it only shows the last few.
But when something's out there and a developer wants it tested, just give a holler, saying "hey, I did this, it's supposed to do this, this is how to test it", and I for one will take a look, so long as it's not stuff that I can't run (which applies to the multi-core code and any GLSL my GPU can't handle).
I've done this process with many of you (core developers) over the years via PM, but I see no reason why this wouldn't work even better in public, especially as I, like anybody else, may suddenly disappear. Better to have a public process for such things.
Maybe put new stuff into a news feed, like ModelBase, where major new features can be submitted for testing and comments?
I would rather see more frequent releases and bug-fixes in a scenario where updates are also more frequent, basically. Not knowing whether the release date on a given feature is weeks or months away is very aggravating as a game developer- it's like putting down money on a roulette wheel. It'd be one thing, if I knew that Feature A was still rough and not available, but that Features BCDE were all on-track for release in the next update... but as things stand, I frequently have to bet on when ABCDE will be available, because it's all-or-nothing, even if BCDE are minor.
The only stopping-point is having an auto-updater for the engine. Can Det's work on the SpringDownloader be used for these purposes?
Re: New Release Plan
Yeah, I'm not too appreciative of just having my name dropped in a thread coming from on high.Auswaschbar wrote:Well, at least you could have informed yourself how the spring release process works before giving suggestions on how to fix it.el_matarife wrote:I'm using "we" so I don't sound like a jerk who's going around blaming people for problems. If you want to launch ad hominem attacks against me for "not doing my fair share" or "living in a fantasy world" go ahead, it just proves that you've got nothing to say about the release process fixes I'm proposing.
Trust me, I hate to write these huge walls of text as much or more than you hate reading them, but we keep having the same issues with the same solutions proposed but never implemented. Most of the stuff I'm talking abut has been adopted with great success at other projects so don't you ever wonder why we're still doing things our own unique dysfunctional way?
Still, releases are about QA, and I think there's a viable amount of volunteers to do the proper QA the next Spring release will need if we just encourage them a bit. The suggestion to advertise features above is a great one, for instance.
Perhaps we should start on a "What's coming in the next Spring (and why you should beta test)" wiki page? That way every little feature someone cares about could be documented really easily, and soon it'll feel like we're all working together on the next release.
Re: New Release Plan
can't delete my own fuckin post wtf !
Re: New Release Plan
only in dev subforumSatirik wrote:can't delete my own fuckin post wtf !
Re: New Release Plan
I'm still new here, but as someone new who came to these forums with the hope of reporting some game-crashing bugs I'd come across, I can hopefully give some useful inputKloot wrote:The main thing I have to say about your proposed release process fixes is that they completely ignore Spring's lack of testers.
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".
What he appears to be doing is trying to recommend changes to the current system. Not everyone is a developer/modder/etc.Regret wrote:Who are you and what have you done for spring?el_matarife wrote:we
Unless you mean to suggest that no-one with X years of modding/developing/posting with Spring may try to make suggestions.