Pages: [1] 2
|
|
|
Author
|
Topic: Revitalizing the Project (Read 9220 times)
|
0xDEC0DE
*Many bubbles*
Offline
Posts: 175
|
I would have brought this up in IRC first, but what I have to say is a mite long-winded for that communications medium. I'm especially interested in comments from coredev:
People around here may not know that the UQM project celebrated it's second birthday a while back. Rather than congratulations, I, for one, see cause for concern:
- The first release was over two years ago, and version 1.0 still has not shipped.
- Version 0.3 shipped over a year ago, and there is little sign that 0.4 is forthcoming any time soon.
- The number of unaddressed bugs for UQM in Bugzilla is growing, albeit more slowly these days. Many of these are dupes of existing bugs, but noone is doing any real "triage" to make sure the real problems remain visible amongst all the chatter.
- Worse, there are bugs that have had patches submitted, that have been ignored for months (and in a very small number of cases, YEARS)
People have asked coredev about this over the years, and the usual response is "we're still working on it, but it's slow-going" That's all fine and good, but more help is usually better than less, provided that the help is competent. So what can we do to attract/provide more help for the project?
I'd like to see:
- More work in the trenches. It would be wise on coredev's part to appoint "lieutenants" to run through the Bug database and triage bug reports (i.e., knock out duplicate bug reports, verify valid bug reports, and invalidate bogus bug reports) so that they may focus on fixing the problems rather than keeping the bookkeeping straight. Anyone who claims that this is currently under control need look no further than the current bug list.
- Some manner of protocol/procedure for public participation in verifying that submitted patches do what they claim, namely a pool of volunteers with compilers and program sources they don't mind trashing. Most importantly, if a patch is deemed functional, coredev will either accept it or reject it authoritatively, rather than ignoring it. Non-functional patches would (obviously) be rejected out of hand.
- More developers actively working on the code. This part is troublesome, because the codebase is so tight that "more cooks in the soup" might be harmful rather than helpful. Hell, I've been submitting patches for years, and it's still fairly evident that I don't know what I'm doing more often than not. But if coredev cannot devote adequate time to the project, and others who are competent enough to do the same work can, what's the difference in the end?
- A stated list of remaining project goals, in some official capacity, for public review. This would mostly be for the purpose of "scaling back" the more ambitious aspects of the project that may be proven to be enormous timesinks with little tangible benefits, as well as attempting to attract people with previous experience coding what needs to be written.
Any more ideas? Any volunteers for the ones proposed so far?
|
|
|
Logged
|
"I’m not a robot like you. I don’t like having disks crammed into me… unless they’re Oreos, and then only in the mouth." --Fry
|
|
|
TiLT
*Smell* controller
Offline
Gender:
Posts: 260
To boldly go where no Spathi has dared go before
|
Yeah! And I also think the remix team should get a swift kick in the rear so that they can get around to releasing that fabled remix pack 4 before we all grow gray hairs! We've waited long enough!
|
|
|
Logged
|
|
|
|
|
Michael Martin
Core Team
*Smell* controller
Offline
Posts: 387
|
There are exactly two "visible" features left for 0.4: the PC intro/outro, and the setup menu. I'm working on the setup menu at the moment. I think fOSSiL is doing the slides.
Doing the setup menu properly is also going to occasion rewriting chunks of the graphics engine, because of certain unfortunate features of the current design. That's happening "now" ish.
Bug triage is something we haven't really been doing, but literally *anyone* can work on that; find bug reports that haven't been commented on and try to duplicate them. If you can't do so, post and say so -- it will let the people who actually write patches know which things to focus on sooner. No official "appointments" are really necessary for either of these.
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
First of all, I agree that it's been going rather slowly, and that that is bad. I still expect this to get better soon, even though I've been saying that for a while now. We are still dedicated to the project, even though we can't dedicate as much time as we'd like.
Now, to some comments on some specific remarks:
- More work in the trenches. It would be wise on coredev's part to appoint "lieutenants" to run through the Bug database and triage bug reports (i.e., knock out duplicate bug reports, verify valid bug reports, and invalidate bogus bug reports) so that they may focus on fixing the problems rather than keeping the bookkeeping straight. Anyone who claims that this is currently under control need look no further than the current bug list.
I claim that this is under control. And I have looked at the current bug list. We now and then clean up those bug reports (in fact, I did so the day before you posted this note). It really doesn't take much time, but it isn't something you need to do every day. An hour or two every two months is enough to keep that aspect under control.
- Some manner of protocol/procedure for public participation in verifying that submitted patches do what they claim, namely a pool of volunteers with compilers and program sources they don't mind trashing. Most importantly, if a patch is deemed functional, coredev will either accept it or reject it authoritatively, rather than ignoring it. Non-functional patches would (obviously) be rejected out of hand.
Functionality isn't the only thing we judge patches on. In fact, I'd say I've rejected more patches because they were badly coded, than that I've rejected patches because they did not work. And those I accepted, I often modified. We want to make the code more clean, and we cannot do that if we accept every patch as-is. It would even mean more work, because bugs in them would turn up later when you don't expect them. The person who decides whether a patch is good (or what to change) has to be someone who whos knows what he's doing, which means he not only has to be a good coder, but also knows the UQM code inside-out (which is no easy thing). No patch is being ignored. They're merely waiting in the "queue".
- More developers actively working on the code. This part is troublesome, because the codebase is so tight that "more cooks in the soup" might be harmful rather than helpful. Hell, I've been submitting patches for years, and it's still fairly evident that I don't know what I'm doing more often than not. But if coredev cannot devote adequate time to the project, and others who are competent enough to do the same work can, what's the difference in the end?
The real problem isn't the bugs that need patching. They're rather small compared to the other things that need to be done. And there are only a few of these "other things", that can't really be split over multiple persons. I'm thinking of the resource system, setup menu, modularisation, and the Windows installer. But if you find someone with good coding skills and a thorough knowledge of the code, I'm sure we can find something for him or her to do. The Windows installer actually is something that a relative outsider could do. Gwl accepted the job of redoing it, but I think he'd rather be working on something else.
- A stated list of remaining project goals, in some official capacity, for public review. This would mostly be for the purpose of "scaling back" the more ambitious aspects of the project that may be proven to be enormous timesinks with little tangible benefits, as well as attempting to attract people with previous experience coding what needs to be written.
Any more ideas? Any volunteers for the ones proposed so far? The project goals are still the same. See The UQM project FAQ in the Ultronomicon.
|
|
|
Logged
|
“When Juffo-Wup is complete when at last there is no Void, no Non when the Creators return then we can finally rest.”
|
|
|
0xDEC0DE
*Many bubbles*
Offline
Posts: 175
|
We are still dedicated to the project, even though we can't dedicate as much time as we'd like. Your dedication was never called into question; I didn't intend this post as a "bitching session", "a kick in the pants", nor was I out to "air dirty laundry", as it were. It seems to have been taken as such, though, which is a shame.
I claim that this is under control. And I have looked at the current bug list. ... No patch is being ignored. They're merely waiting in the "queue". Bugs #273, #46, #411, #391, #462, #470, #362, #291, #503, #514, #533, #499, #557, #558, #341, #315, #502, #44, #592, #559, #516, #32, #611, #571, #363, #50, #602, #183, #617, #629, #43 and #46 are currently listed in Bugzilla as "open bugs", and all have patches attached to them. Some have actually been applied to CVS and the bugs not closed, most have no opinion from coredev regarding their status whatsoever. And I'm not even counting the number of bugs in Bugzilla that aren't actually bugs (i.e., duplicate reports, or user-didn't-RTFM "bugs") Would you care to explain your opinion that you've got it under control in the face of such compelling evidence to the contrary?
And I might add, a queue that isn't being processed is not a queue.
The real problem isn't the bugs that need patching. They're rather small compared to the other things that need to be done. ... But if you find someone with good coding skills and a thorough knowledge of the code, I'm sure we can find something for him or her to do. I've been fully aware that you've all got "bigger fish to fry", and that was the bulk of my reasoning in writing this in the first place -- to try and get you gentlemen additional help where you can use it, and to help free you from the minutae of dealing with "the little stuff" by letting others handle it for you; and more importantly, drumming up more interest in the game, as well as the project. I'm sure it would not be considered a bad thing if more people knew about the game than less.
And it might be worth a moment's consideration whether the better approach is "finding something for someone to do", or "letting people find something for themselves to do."
|
|
|
Logged
|
"I’m not a robot like you. I don’t like having disks crammed into me… unless they’re Oreos, and then only in the mouth." --Fry
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
Your dedication was never called into question; I didn't intend this post as a "bitching session", "a kick in the pants", nor was I out to "air dirty laundry", as it were. It seems to have been taken as such, though, which is a shame.
Not really. I read it as an attempt to provoke the existing people to more activity, with a hint of frustration over your patches that are still waiting. I surmised this as I suspect that you realise that in practice your suggestions to get others involved would not work.
Bugs #273, #46, #411, #391, #462, #470, #362, #291, #503, #514, #533, #499, #557, #558, #341, #315, #502, #44, #592, #559, #516, #32, #611, #571, #363, #50, #602, #183, #617, #629, #43 and #46 are currently listed in Bugzilla as "open bugs", and all have patches attached to them. Some have actually been applied to CVS and the bugs not closed, most have no opinion from coredev regarding their status whatsoever. And I'm not even counting the number of bugs in Bugzilla that aren't actually bugs (i.e., duplicate reports, or user-didn't-RTFM "bugs") Would you care to explain your opinion that you've got it under control in the face of such compelling evidence to the contrary? Fine, leave out the context to my reply. What I was claiming we had under control was exactly the stuff you aren't counting now. The "knock out duplicate bug reports, verify valid bug reports, and invalidate bogus bug reports". As for the rest, well, the number of bugs is only growing slowly, and most new reports are feature requests. So I wouldn't say it's "out of control". Which means it's under control.
|
|
|
Logged
|
“When Juffo-Wup is complete when at last there is no Void, no Non when the Creators return then we can finally rest.”
|
|
|
|
|
0xDEC0DE
*Many bubbles*
Offline
Posts: 175
|
Since my motives now seem to be called into question, I'll make myself perfectly clear: I am not out to advance some hidden agenda, I have no ulterior motives in voicing my concerns such as "being frustrated that my patches aren't getting applied". To even assert such a claim flies in the face of common sense -- I've been maintaining my own fork of the game with all of the patches applied that I care to have applied for some time now, I don't need features to go into CVS in order to use them. And it's not as though I have a long and sordid history of getting into spats with coredev over patches I submit -- I ask your opinion of them and you either accept or reject. Either way, I have always dropped the issue once a final decision is made, and I'm at a loss to understand how such a position can cause offense (or for that matter, resentment).
My only motivation is, and always has been, in seeing the project actually get finished, and I would think the record would be quite plain in showing that I have always been willing to do anything and everything that lies at the intersection of "things that need to be done" and "things I am able to do" in order to see that goal realized.
The problem, from my point of view, is that it's getting harder to find the things that need doing. Naturally this is due in part to the fact that the project is so very close to completion, the bugs are bound to become more esoteric in nature, and the features of increasing complexity to the point where an extraordinary familiarity with the code would be required. But I would also place the blame partly on the fact that, if you'll excuse my candor, that the bug database is an absolute mess, the project goals are abstract to the point of useless, and coredev doesn't seem to care and/or doesn't have the time to straighten things out or provide any future direction for people who want to help. Whether or not you're holding things steady is irrelevant, the status quo is pretty lousy as far as I'm concerned, and there's plenty of room for improvement. Pointing out what some of the problems are (and spitballing some ideas on how to improve them) was the primary purpose of this topic.
When someone who has been contributing for over a year now is having trouble navigating the waters, what does that say for the possibility of attracting new contributors? To your credit, you gentlemen have kept an amazing focus on keeping the code "clean", but I think it has come at the expense of "keeping the affairs of the project in order" which is almost equally as important, especially with open source projects.
That the Ultronomicon project is so close to completion in a scant two months shows that you have plenty of pedantic and anal-retentive folks (no offense intended, of course; is anal-retentive supposed to be hyphenated? ) perfectly willing to run through and sort out what is by its very nature a complicated mess, so why not use that to your advantage and turn some of them loose on your buglist? It'd be hard for them to make the situation any worse.
In short, I couldn't care less whether you want any help, from my perspective, you need help, and all I was trying to do was drum up some support/ideas/enthusiasm/whatever for getting it to you. If I'm wrong and you don't actually need any more help, then prove it and ship something; that way everyone will be happy.
|
|
|
Logged
|
"I’m not a robot like you. I don’t like having disks crammed into me… unless they’re Oreos, and then only in the mouth." --Fry
|
|
|
|
nightshadow
Frungy champion
Offline
Gender:
Posts: 64
The PT-Masters are coming...
|
All in all this has been a great thread to read.
I think 0xDEC0DE has a point, and I have not understand his post as "bitching" or something like that.
I do agree that the project is really slow going, but hey... I've also got projects of my own and when real life knocks, you gotta answer. So from years surfing this kind of projects I've learned to be patient. I'm gratefull that I am able to enjoy UQM for what it is. Thanks guys.
Anyway it seems that the project team needs to sort out the project priorities to help them go trough the stuff missing, now that they do not have much time to dedicate to it.
I am no coder, but from a gamers point of view the game is quite finished (the intro and the ending slides being the only important thing that's been left out).
So, why not:
- Aply the patches; - Implement the menu (I know it's being worked on) - Implement the slides (same as above)
and release version 0.4?
You could left every other bug to the next version (probably 0.99, or Release Candidate).
For me, I'm only waiting for the slideshow to introduce the game to some friends of mine.
Please to not understand my post as a "bitching" post, but rather as a thank you post with some sugestions on it
Thanks guys. Keep up your great work.
|
|
« Last Edit: October 27, 2004, 02:44:56 am by nightshadow »
|
Logged
|
Best regards, Night Shadow
|
|
|
|
|
|
Pages: [1] 2
|
|
|
|
|