Le jeudi 21 février 2008 à 23:31 -0600, John Goerzen a écrit : > On Thursday 21 February 2008 8:22:49 pm Don Armstrong wrote: > > I think it's going to be in our long term interest to identify some > > more of these packages that could use help and figure out what changes > > (if any) need to be made to the BTS, documentation for those packages, > > and anything else to help new people get into triaging these bugs. Well, we’ve been aware of this issue for quite some time, but no magical solution was proposed so far. A large part of the solution is probably to make bug triaging look more sexy, so that it attracts more people. > 1) Large projects using $DVCS and making it easy for people that aren't > familiar with $DVCS to learn how to participate in that project. How is this relevant to the bug issue? I have the impression that DVCS fanboys are trying to bring them in all discussions. > 2) Potential ways to assign bugs to particular contributors or subprojects > that don't occur at binary package boundaries. That could help for large beasts such as mozilla or OOo, but unfortunately the barrier to them is high, even for understanding a small subsystem. Even though, in KDE and GNOME which have better separations between components, we have a hard time finding people to help in specific areas. > 5) A way of sorting bugs by "hack on this first". Our priorities are not > necessarily this way. For instance, we may have a wishlist bug to package > the new upstream and a serious bug that is caused by a bug in the current > upstream and may be fixed by the new upstream. Makes sense to do the > wishlist bug first and then test to see if it's gone away. In a sense, we > need a field that means nothing to anybody except the maintainers, and is a > value that the maintainers can use for whatever purpose they like. We already have usertags. They could be made easier to use, especially so that the maintainer can define a default view for the package, but this only helps seeing bugs that have *already* been triaged. > 6) Better tools to integrate Debian BTS with upstream BTS. I would love a > command-line tool where I could say "debforward 123456". It would look up > the package name for 123456, figure out from some metadata what type of BTS > it uses and where it lives, look up my account on that BTS in ~/.forward, > and create a bug report there and mark the Debian one forwarded. Then, if > there is no automated mechanism, some scanner at Debian would look for > changes on either end and forward them back and forth. I would love this. The hard time in forwarding is not copy-pasting stuff in a browser. What takes more time is investigating whether the bug has already been submitted, and whether it has already been fixed in the VCS. > 7) Perhaps even a change of policy on upstream bugs. If the Debian > maintainer is really sure a bug is upstream, it should be a valid response > to close it in Debian with instructions on submitting it upstream and > reopening it in Debian if upstream believes it's a Debian issue. There's a > lot of work just schlepping data between upstream and end users for things > that aren't really Debian issues. Again, the hard time is to identify that this is actually an upstream issue. Even so, you can’t always been sure. It would be counterproductive to play ping-pong instead of having the opportunity to remove the forwarded tag if the upstream maintainer finds out it is actually related to Debian. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=