On Tue, Jul 08, 2008 at 12:25:40AM +0900, Emmet Hikory wrote: > Scott Kitterman wrote: > Setting up an automatic install / upgrade / remove / purge tester > would be good, perhaps using piuparts or similar infrastructure, > although this requires considerable resources in terms of local > storage and processing power. There are likely also several other > automatable targets in terms of package state or archive consistency > that would benefit from additional tools to track them. > > > I'm not certain, however, that we need more bugs. We need better bugs and > > we > > need more fixes. Suggestions?
I'd like to emphasize this point. If you're trying to make water flow through a piping system, you might first try turning up the incoming flow, but eventually you need to switch to bigger pipes. Ubuntu has seen huge growth in popularity, and I believe this is the primary source of increased bug report flow. More early testing would be helpful in initiating this flow earlier on in the development cycle, but what we really need is to increase the pipe size downstream so we get an increased flow of fixes out the end. > In recent times there seems to be some disconnect between the > presence of bugs and the presence of developers working on these bugs. >From user comments I often get the sense that if only we could get the attention of "Those Developers" to work on bugs instead of whatever other obscure work they're doing, these bugs wouldn't be a problem. But "those developers" are really us right here. Some of us work for Canonical, more are Ubuntu community members such as members of this list, and the vast bulk are general community members in upstreams, other distros, etc. Unfortunately, there's a limited number of developers in existance. We can definitely improve things somewhat via better upstreaming of bugs, however we run the risk of saturating the upstreams if we merely shifted all of our unprocessed bug work there. Ultimately I think the true solution is to increase the pipe flow by increasing the number of people doing development work. I am a strong believer that those of us who *are* developers have a duty to find ways to help other people become developers. I feel the old adage applies, "Give a man a fish, he'll eat for a day; teach a man to fish, he'll eat for a lifetime." So I would encourage looking at ways we can help the average bug reporter take on more of the work of troubleshooting the bugs they find. After all, they by definition already have the necessary equipment and environment for doing the testing. The first step is to have good, detailed documentation to make the process as 'paint by numbers' as possible for them - I've been making attempts at doing this via docs at http://wiki.ubuntu.com/X/, and by improving the description section of frequently encountered bugs. Second is to remove major hurdles that are inhibiting them, such as to enable them to test against recent git versions (which upstream often asks for), provide packages of test versions, etc. > We should also be better about chasing bugs that are fixed. There > are a number of bugs marked fixed upstream, or fixed in Debian, or > with patches. There are plenty of others for which there are good > fixes in Fedora, SuSE, Gentoo, etc. At least in those cases where we > can track that a given bug exists in Ubuntu and a fix is available, we > ought assiduously chase these: the more quickly we can go from a fix > being available somewhere to a fix being available in Ubuntu, the more > likely we are to be informed of a fix being available somewhere, and > the better chance we have of a relatively small number of bugs. Yes. A huge part of my week-to-week work the past few months has been exactly this. I've scripted a few bits and pieces of my procedure, and I dream of a day where the bulk of the process could be automated into a web script. User pastes in a git ID, which churns and spits out a .deb; user installs, tests, and says, "This fixed it"; this triggers a workflow bug for a developer to review and ok the integration of the fix. In addition to saving a lot of developer time, this would eliminate most of the cycles between user / bug triager / developer that make bug fixes take so long to produce. Bryce -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
