On Thu, Jul 28, 2005 at 09:22:56AM -0700, Donnie Berkholz wrote: > Jason Stubbs wrote: > > | The reason behind this is that at approximately two thirds of bugs > received > | are feature requests and they are drowning at the real bugs. More > importantly, > | the critical bugs are becoming very hard to keep track of. This, at a time > | when we are focusing on fixing major and critical bugs only so as to > get the > | next version completed quicker. > > Are you having a tough time filtering out enhancements in your queries > or something? I don't understand how feature requests could possibly > interfere with anything besides other enhancements.
Well... we have over 350 bugs open (roughly). How do continual "we want xyz implemented" screw with things? Dupes up the wing wang, lot of continual requests for the same thing, etc, lot of old bugs that need attention but get drowned out by new bugs (or new bugs that flat out miss old bugs due to their age). Basically, this is a bit along the lines of trying to keep things easily filterable so that people who want to work on portage can quickly see what relevant (stable) bugs exist, and can dig up the feature requests (fricking multitude of them). The feature requests aren't being ignored, the issue comes down to what I stated in an earlier email on this ml; with the current code, if it were easy to pull it off, we would do so without hesitation already- most of the features *can* be pulled off without too much hackery, but it requires (long needed) changes to portage innards. Two main thrusts of work at this point, stable bug squashing, and rewriting sizable chunks of the underlying portagelib code so that the feature requests (sync per repo, seperated caches per repo, use deps, slot deps, EAPI changes, glep33, glep37 (potentially), better binpkg handling, drop md5/mtime as default for unmerge checks and use refcounts, framework for remote, etc) are doable. Essentially it's squashing old noise on the bugs till we can actually address it. Like I said above, two main thrusts of work are stable, and mangling the codebase so that we can actually pull this stuff off, and with the limited # of people hacking on portage, more time devoted to that the better. So... yeah. not dodging bugs, just need a way to do something about massive # of older bugs and noise on the bugs ml. Man power issues somewhat, but mainly trying to focus on taking care of what needs to be taken care of right now. Patches make a world of difference, since it A) involves people in the code, B) allows us to work on what needs to be addressed *now*, without digging about for a feature that in the grand scheme, doesn't matter too much. Clarifiaction of B, which matters most in the long run, a UI change, or use deps? Etc. pardon the long winded explanation... It's something that has been toyed with for a while, and so far we (portage devs) seem to think it's a good way to at least get a handle on the current mess. ~harring
pgpkZeoZ7XO9B.pgp
Description: PGP signature
