Re: [hlds_linux] Feature Request/Bug Tracker
-- [ Picked text/plain from multipart/alternative ] I can't help with the customisation, but I certainly can help with providing the bugs. On 11/24/06, Erik Hollensbe <[EMAIL PROTECTED]> wrote: > > > On Nov 23, 2006, at 3:31 PM, Whisper wrote: > > > -- > > [ Picked text/plain from multipart/alternative ] > > The only problem I can foresee, is that the bug list could end up > > as a giant > > list of client side exploits and how to reproduce them, which > > although does > > not deal directly with HLDS/SRCDS, becomes our problem as server > > administrators, as we nearly always end up having to implement some > > sort of > > solution to fix it. > > EXCELLENT point. Obviously the system would need the ability to > obscure certain information. This could also be accomplished by a > external<->internal bridge for valve, whereby moving things to their > internal tracker, they could be removed from the external one (with > an optional mark saying, "we've heard about this, etc.") > > > Do you have a bug tracking solution in mind btw? > > If so, which one? > > Personally I think bugzilla is a good solution for this. I have > experience customizing the system, am (very) familiar with the > implementation language, and bugzilla really has unprecedented > flexibility (except for some of the Rational tools, perhaps). > > Obviously though, a lot of this is weighing in on my personal > experience - if there are other parties interested that want to chime > in on the condition that they are interested in developing such a > system, I'm all ears. > > To translate: I don't think it's worth throwing in your $0.02 on > software choice unless you're willing to help customize the system. > > > I still have a rather long list of existing bugs. :) > > I imagine you're not alone, but such is the nature of software > development. > > -- > Erik Hollensbe > [EMAIL PROTECTED] > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature Request/Bug Tracker
On Nov 23, 2006, at 3:31 PM, Whisper wrote: -- [ Picked text/plain from multipart/alternative ] The only problem I can foresee, is that the bug list could end up as a giant list of client side exploits and how to reproduce them, which although does not deal directly with HLDS/SRCDS, becomes our problem as server administrators, as we nearly always end up having to implement some sort of solution to fix it. EXCELLENT point. Obviously the system would need the ability to obscure certain information. This could also be accomplished by a external<->internal bridge for valve, whereby moving things to their internal tracker, they could be removed from the external one (with an optional mark saying, "we've heard about this, etc.") Do you have a bug tracking solution in mind btw? If so, which one? Personally I think bugzilla is a good solution for this. I have experience customizing the system, am (very) familiar with the implementation language, and bugzilla really has unprecedented flexibility (except for some of the Rational tools, perhaps). Obviously though, a lot of this is weighing in on my personal experience - if there are other parties interested that want to chime in on the condition that they are interested in developing such a system, I'm all ears. To translate: I don't think it's worth throwing in your $0.02 on software choice unless you're willing to help customize the system. I still have a rather long list of existing bugs. :) I imagine you're not alone, but such is the nature of software development. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature Request/Bug Tracker
-- [ Picked text/plain from multipart/alternative ] The only problem I can foresee, is that the bug list could end up as a giant list of client side exploits and how to reproduce them, which although does not deal directly with HLDS/SRCDS, becomes our problem as server administrators, as we nearly always end up having to implement some sort of solution to fix it. Do you have a bug tracking solution in mind btw? If so, which one? I still have a rather long list of existing bugs. :) On 11/24/06, Erik Hollensbe <[EMAIL PROTECTED]> wrote: > > About 6 months ago this was being discussed, and never came to > fruition. A *lot* of the questions/comments here these days have less > and less to do with supporting the system as much as requests to > modify it in some fashion. > > I think it would be not only wise, but prudent for valve or a > secondary party to implement a bug tracker or feature request system > that would allow people to effectively petition features/bug fixes > assigning a priority to the things that are most important to the > guys who run the servers. Obviously, it wouldn't be that bad of an > idea to tackle this in the client as well. > > The advantages for valve would be several-fold - not only would you > have a backlog of all the things that your constituents are > complaining about, but a petitioning system would allow valve to see > priority based on the number of people who are interested in seeing > this fixed. Several techniques can be used to minimize inflation of > voting for requests, but obviously won't eliminate the problem. > > The advantages for users would be several-fold as well - instead of > clogging up the list with the 400th thread that starts with, "Where > is the 64-bit VAC2 support?" One email gets out, and someone replies > with a bug number and everyone can see that the bug is marked by > valve administrators as "WON'T FIX". Not only is it clear to everyone > that the bug is already known, it's clear to everyone that valve has > no intention of tackling this problem anytime soon (if at all). > > Obviously there's a relations issue here - people are undoubtedly > going to get bent out of shape when they see something tagged as > "WON'T FIX", but in reality that's no different than the current > situation. The above-described situation actually lends to clearing > up confusion, simply because the lack of responses by staff has, in > the past, caused more problems than is really necessary. > > This simply doesn't work unless Valve and the community participates > - if one of them decides that it's not going to work, the whole point > is lost. Undoubtedly, Valve has their own internal trackers and a way > to ease the transition from moving to the public database to the > private one would be a big bonus for them, I imagine. > > So, I'll offer again - if there is significant interest by Valve and > the community, I'm willing to extend as much help as is attainable to > make this happen, whether that be writing code, providing ideas, or > administering/hosting the service. > -- > Erik Hollensbe > [EMAIL PROTECTED] > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] Feature Request/Bug Tracker
About 6 months ago this was being discussed, and never came to fruition. A *lot* of the questions/comments here these days have less and less to do with supporting the system as much as requests to modify it in some fashion. I think it would be not only wise, but prudent for valve or a secondary party to implement a bug tracker or feature request system that would allow people to effectively petition features/bug fixes assigning a priority to the things that are most important to the guys who run the servers. Obviously, it wouldn't be that bad of an idea to tackle this in the client as well. The advantages for valve would be several-fold - not only would you have a backlog of all the things that your constituents are complaining about, but a petitioning system would allow valve to see priority based on the number of people who are interested in seeing this fixed. Several techniques can be used to minimize inflation of voting for requests, but obviously won't eliminate the problem. The advantages for users would be several-fold as well - instead of clogging up the list with the 400th thread that starts with, "Where is the 64-bit VAC2 support?" One email gets out, and someone replies with a bug number and everyone can see that the bug is marked by valve administrators as "WON'T FIX". Not only is it clear to everyone that the bug is already known, it's clear to everyone that valve has no intention of tackling this problem anytime soon (if at all). Obviously there's a relations issue here - people are undoubtedly going to get bent out of shape when they see something tagged as "WON'T FIX", but in reality that's no different than the current situation. The above-described situation actually lends to clearing up confusion, simply because the lack of responses by staff has, in the past, caused more problems than is really necessary. This simply doesn't work unless Valve and the community participates - if one of them decides that it's not going to work, the whole point is lost. Undoubtedly, Valve has their own internal trackers and a way to ease the transition from moving to the public database to the private one would be a big bonus for them, I imagine. So, I'll offer again - if there is significant interest by Valve and the community, I'm willing to extend as much help as is attainable to make this happen, whether that be writing code, providing ideas, or administering/hosting the service. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
