|
|
Closed some of the issues. For reference, though, engine mantis has 244 not-resolved, not-closed issues, and engine devs close "unwanted" reports much more than we do. This is probably an atypically low figure: the Arcen Games mantis (commercial company!) has 2039 such issues spread out over 5 or so games. But yeah, issues tend to be forgotten if not resolved within a few days :/
+0 / -0
|
Also the priority system is stupid. There have been FIXRIGHTNOW bugs that hang around for months (Disregarding how bad a priority called "FIXRIGHTNOW" is just by itself). It makes it hard to sort out if there are any problems blocking a stable release. And I don't think the bug reporter is the right place for balance QQ or crazy feature requests, but that is imho.
+0 / -0
|
I don't think the bug tracker is very useful, most reports are rambling, impossible to reproduce, are discussions rather than issues, are inconsequential, and the reporter often cannot even correctly identify the issue. We only have so much dev time to try and figure out what most reports are even about, which is required to properly resolve the ticket. I suppose there are other more active devs who find the system useful though.
+0 / -0
|
Of course bug tracker system is useful. Most bugs are real bugs and are either resolved or accepted as unresolvable. FIXRIGHTNOW was intended to block release but if hard to fix bug is marked as such nobody will delay new version because of it. Also there is no management that would force devs to simply fix most annoying bugs. Devs tend to work on new stuff rather than fixing exisitng.
+0 / -0
|
quote:
FIXRIGHTNOW was intended to block release but if hard to fix bug is marked as such nobody will delay new version because of it. |
"Blocking" should be the problems that, if they pass into a stable release, require hotfix release immediately afterwards because they break the game. These things happen every now and then, and we get a slew of hotfix releases after a stable release. Perhaps there should be an even higher priority called FIXRIGHTNOWSERIOUSLY!!!!!!!! because multiple exclamation points and caps are good ways of letting people know that you mean business. Also, I don't think the bug tracker needs to include issues like this one: http://code.google.com/p/zero-k/issues/detail?id=1774
+0 / -0
|
I share abma's frustration. quote:
Also there is no management that would force devs to simply fix most annoying bugs. Devs tend to work on new stuff rather than fixing exisitng. |
It can be done. And it should be done. "Want to add that new extra feature that you'll feel great while coding it? Fine, then fix that other bug assigned to you before your shiny new feature gets accepted into main branch". I know, I already rambled uselessly many times about the lack of branches and the recurring revert-craze caused by lack of communication/management. I know it won't change, I just wanted to point out that another model is possible. If the message is, this issue should be closed rather than left as it is, I agree. if the message is, people should not be allowed to post new issues because most are dumb, I disagree (on the permission to post, not necessarily on the latter part).
+0 / -0
|
Slightly off-topic, but complement to my last post. No wonder devs do not have time to handle the bug tracker. Mixing experimental developments by "new-developpers", new features by seasonned developpers, bug fixes and changes forced by new engine releases all in a single branch results in this kind of commit-revert cycles. Nobody want to learn a new tool when what they have is appropriate. But ask yourself, is the current dev workflow really working? Are the tools appropriate? Another way to do it: https://jellyjelly.net/blog/2012/05/04/our-git-development-workflow/
+0 / -0
|
I'm disturbed by your moralizing post sheep. Devs have no problems "learning new tool", In fact I'm using git for other projects! Problem is two fold: 1) infrastructure- who will port it, secure reliable hosting, convert necessary tools - for example builder for rapid is written in ML functional language and hooked directly to SVN using compiled libs. Builder that builds website on DEPLOY_SITE also connects directly to SVN .. Its probably a week project full of annoying issues you have no idea about. If you want to lecture, volunteer for this and you can start be changing that ML tool for rapid. 2) git performance- ZK repo is 2.6GB mostly of binary files! Git is not good with that clone operation would be very very slow. There is also issue of steep learning curve for new developers. I had to install certificates and SSH tunnel in putty to achieve smooth workflow on windows (without me having to enter password every damn time i commit).
+1 / -0
|
Oh btw there is also a problem with the development workflow link you posted... WHO will do the gatekeeper? Its precisely what we are missing, nobody want's to test and fix stuff other people made! We don't have reliable volunteers to do that.
+0 / -0
|
I am already game-side gatekeeper by default and I assumed others gatekeep 'their' areas. It would be easier for me if I had to expend effort to let things in to the repository but you'd get less contributions.
+0 / -0
|
The only reason the main dev branch is kept playable is that it feeds directly into the stable version. Any dev branches would quickly get outdated. We used to have these and that's what happened. I agree we should manage random contributions by people who don't know what they are doing better, but their work making it into the live version is one of the major reasons we get contributions (something like ZK-dota to a luaui script). That workflow proposal is just impossible for us. We do not have a gatekeeper who even understands every component game, there are art assets, animation scripting, lua, lups, and all the support and website stuff. Edit: Wow 9 seconds apart and google basically said exactly what I did only more succinctly. There is always room for improvement but it's not as simple as you make out sheep.
+0 / -0
|
There are already local gatekeepers, i assume you dont read ZKL or site commits.. its up to me..
+0 / -0
|
quote:
I'm disturbed by your moralizing post sheep. |
You are free to ignore what I'm saying. The link I posted may not be a perfect answer to the problem at hand... but I'm pretty confident that the problem I describe is real (commit-revert cycles... like right now, when working on 0.92, but having to release a minor zk revision for 0.91). So either ignore my assessment of the situation. That doesn't make the problem go away (and the frustration of devs in #zkdev when they have to revert/explain why something that made into the main/only branch is broken and must be reverted). Or acknowledge that things are not ideal and discuss possible solutions. That means, explaining where are the problems to switch to another model. quote:
2) git performance- ZK repo is 2.6GB mostly of binary files! Git is not good with that clone operation would be very very slow. |
I'm not sure why lobby, website, artworks and mod are all in a single repository. Obviously, repository is big because its not broken down into functionnal areas. Am I allowed to even consider that this may not be the only way to do it? quote:
WHO will do the gatekeeper? |
quote:
I am already game-side gatekeeper by default and I assumed others gatekeep 'their' areas. It would be easier for me if I had to expend effort to let things in to the repository but you'd get less contributions. |
quote:
That workflow proposal is just impossible for us. We do not have a gatekeeper who even understands every component game, there are art assets, animation scripting, lua, lups, and all the support and website stuff. |
Seems to go in the same direction as my prev answer... break down repository by functionnal areas. I'm sure nobody would be the one and only gatekeeper for all zk stuff, and it wouldn't make sense. I'm also sure there is a "natural" gatekeeper for zkl, website, and mod. And there may be a need to further break down the mod, into areas like units+models, chili/UI, widgets and whatever. I don't know, but there is at least 2-3 persons who know it and could help. If those persons don't want to help, I'm sure I can't help propose a solution tailored for zk, then you can say "your proposal is bullshit because you are just ignorant" with full satisfaction (note: the original problem didn't go away -- experimental features still leak into releases occasionaly, you must revert all current changes for 0.92 because you have to release 0.91.x again, etc). quote:
Its precisely what we are missing, nobody want's to test and fix stuff other people made! We don't have reliable volunteers to do that |
Seriously, does this mean "just let players test it for us"? It would be much easier to find people to test a single changeset that is clearly identifiable... right now, using a test release is a mixed bag of surprise, you don't even know what has to be tested. So what do you do... you play a game, which is somehow expected to exercise/cover all features that have changed. Then you release. Then someone gets angry because feature XYZ has bugs and its a drama again. quote:
1) infrastructure- who will port it, secure reliable hosting, convert necessary tools - for example builder for rapid is written in ML functional language and hooked directly to SVN using compiled libs.
Builder that builds website on DEPLOY_SITE also connects directly to SVN ..
Its probably a week project full of annoying issues you have no idea about. If you want to lecture, volunteer for this and you can start be changing that ML tool for rapid. |
I may consider helping. But only if I get constructive help about what are the main issues and not "you have no idea about it". This touches every part of the code/dev model and I can't reasonnably understand it all. Only things that I fully understand are the commit-revert problem and frustration/bad communication among devs. If there is resistance to change/help, I may just abandon the idea, and post another such post in 1 year... reminding you that maybe, things could be organized in another way... which would have prevented the last "zomg this shitty feature made its way into the release and we need to blame someone -- but we can't change anything to the devmodel because our repository is 2.6GB and because our project is so big nobody understands it all".
+0 / -0
|
We actually do very well with what we have, we have a very stable product under constant development from engine to art, coding to balance. We keep a live, playable, excellent product through all of that. In so far as we do have fundamental problems with communicating across different skill sets or bugs not being found until they make it into the live version, infrastructure changes will not fix them. It might fix a lot of smaller complains like zk-dota or wiki changes appearing in the changelog, but sometimes we need our whole playerbase playing to detect a bug, and sometimes everyone working on the same branch is the only reason it's kept stable. Improvements to the infrastructure are not the panacea which will make all our bug reports disappear, but I'm all for improvement! Of course, this isn't my department so I can neither offer to help nor give approval.
+0 / -0
|
We don't have an SIMPLE TO DO option to let people test things without adding them to every game by updating the source ... We should use widget/gadget enabled=false (by Default) and add some clearly visible options where players can test them * without the need to install 1000 packages, learn how to compile, about the folders, etc - I think most peoples simply get annoyed to manage their options/stuff. * and write feedbacks without have to search for the web-user-form We "just" need to: * separate the newly added experimental from the others * allow "active by default" only for tested packages where enough peoples vouch for * code an ability for a new experimental gadget/widget or newer version of an existing one, which can only crash the game when it gets explicitly activated for the game/host * implement a feedback function in-game or on zero-k.info ^^ We should start a tourney for the best ideas how to do these things ^^ (BTW: I don't use the zklobby, because of linux, idk what it has already)
+0 / -0
|
|
|
1. oops, does this board some notification about new posts? 2. i didn't want to start a thread about critism about all, many things are really good. i think its good that you release from development branch, some times you break stuff but sometimes it is funny/interesting for gamers, too because of bugs (as long as its playable). 3. what i just wanted to "start" is a discussion about a shared todo-list and the bug-tracker can/could be used for that. but it seems only a few devs are using it, and thats imo bad. but to use it as such thing its bad to have a list of 600 random things and some are already done and some not... be a bit more harsh about closing bugs / feature requests! if bugs are impossible to reproduce: request more info and/or close it... keeping it open forever doesn't help anything, it just wastes time other people reading it over and over again. 4. about git: if you split up stuff in different repos i guess you'll have no problems. The linux kernel is also in a git repo and its much bigger... afaik github has an automatic svn bridge/repo, so it could be used easily, but thats not so important i think 5. SinKitty idea sounds good, but regression tests could help, too... just my two cents, keep on going, you're doing well! :)
+0 / -0
|
Regarding 1 - not much, but if you login to zero-k and go to "home" you see "posted threads" and they are bold if they have unread new posts. I think that to really take advantage of git, we would need to change tools to access git directly and make different builds for different branches and tags automatically (this could be done with svn too).. Basically problem now is not testing without commiting to master. SVN itself supports branches and tags but nobody uses them because it does not make testing any easier.
+0 / -0
|
quote:
We actually do very well with what we have, we have a very stable product under constant development from engine to art, coding to balance. We keep a live, playable, excellent product through all of that. |
Yes, thats true, the game is great and its moving forward. There is no question about it. My point was, it takes a lot more effort than required to do so. Also, I'm sure you could use more developpers to improve things even more/faster. But how things are currently done, adding more developpers means adding more work for "core devs" just to keep things under control. And its not possible to try new things if you can't be around #zkdev at all time, because when a need for a minor release happen, everyone gets crazy ("where is A?" "did he test his things?" "can we release it?" "lets revert everything he made"). My comments were not really advocating for git over svn, but more about using branches. Of course the example given was about using git because that's what cool kids currently love, but the "workflow" was the important theme. Maybe git isn't currently easy to use for microsoftees, but I guess this is about to change: http://techcrunch.com/2013/01/30/microsoft-announces-git-support-for-visual-studio-team-foundation-server-and-service/Hours after I made my post in this thread: quote:
r9640 Unrevert stuff non-UI stuff (mission_orbital drop speed, morph priority, new scythe icon)
r9639 Unreverted luaui updates involving ui. Before anyone makes a stable, host a springie game with latest test. Choose advanced and host zk:revision:####
r9638 VERSION{v1.1.2.12} Reverted incomplete keybinds work. Everything should go back to normal.
r9637 Reverted Epic Menu to before r9447.
r9636 Revert previous.
r9635 Reverted previous. Epicmenu - restored code. Integral menu - uses zk_keys.
r9634 Revert back to r9606 (v1.1.2.9) with the exception of r9609, r9615, r9624, r9627, r9630.
r9633 Revert previous commit.
r9632 VERSION{v1.1.2.11} Revert to prev stable.
|
Who is able, by reading those commitlogs, to say what is currently in the repository? Its hard to follow progress. Similarly, its hard to just see what changes made through up to the release point. Maybe there is no advantage in this project to use 1 branch per feature (or rather, its overcomplicated). But using 1 branch per release and ensuring that not everyone commits to the release branches (by actually having 1 dev + 1 curated release branch per version) would prevent such back-and-forth jitter. And when moving stuff from the dev branch to the release branch, it would be a good time to review tickets. There is no point for a dev to close tickets when you commit a fix that may be reverted later because of an urgent need of minor release and which may not be "unreverted" subsequently. Whose job is it, to "unrevert the reverts"?
+0 / -0
|
