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