Re: On Launchpad Bug Status values
On Sun, 28 Oct 2007 09:20:41 +0900 "Emmet Hikory" <[EMAIL PROTECTED]> wrote: >A month ago, an official list of Bug status values was published >on launchpad [1]. Without a discussion of the appropriate >classification of the various statuses that are used to track bugs >that may someday be fixed, I would like to hear if other MOTUs would >find an additional rejection status would be useful, defined as >follows: > >"Deferred" > >This status indicates that while this bug is valid, and there is >sufficient information to understand the cause, there is no current >intention to fix the problem by the project against which the bug is >reported. Deferred is meant to capture the cases where a reporter's >request is unlikely to be addressed in the project, and the reporter >would do well to pursue other channels in parallel. > >"Deferred" is distinct from "Invalid" in that an "Invalid" bug >represents a case where a bug doesn't represent something that can be >fixed, whereas "Deferred" bugs could be fixed, but nobody is going to >do it. > >"Deferred" is distinct from "Won't Fix" in that "Won't Fix" represents >a case where either the perceived problem or recommended solution is >contrary to the plans of the project, or the scope of the issue is >beyond the ability of the project to complet, whereas "Deferred" bugs >represent soluable issues. I think that the first part of your Won't Fix definition is actually Invalid. I think the 'We're not going to fix it, it needs to be done upstream from here" case is best represented be an upstream bug watch and Won't Fix in Ubuntu. It's not always big bugs. There may be an issue that's trivial enough not to be worth fixing in Ubuntu because of the overhead associated with going from syncing the package to it needing to be merged. This can also be dealt with if the upstream task doesn't exist with a bug comment suggesting to the reporter where better to file the bug. Personally, I think we already have to many bug status choices. I have seen little value in trying to distinguish Confirmed and Triaged. More complexity in the data model is a negative that should be avoided if it can be. I don't see a compelling reason to accept this additional complexity. As an added bonus, recent attempts to add automatic bug status changes to Launchpad have not gone well. I think that in the near term there is significant risk such a change would have unintended consequences. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: On Launchpad Bug Status values
Emmet Hikory wrote: > "Deferred" > > This status indicates that while this bug is valid, and there is > sufficient information to understand the cause, there is no current > intention to fix the problem by the project against which the bug is > reported. Deferred is meant to capture the cases where a reporter's > request is unlikely to be addressed in the project, and the reporter > would do well to pursue other channels in parallel. Tony Yarusso wrote: > Could this status also be used for cases of "This is a legitimate bug, > but the project developer does not have the knowledge necessary to fix > it at this time. You may need to wait a while until they do, or it > may be more efficient to offer a bounty to someone else, in which case > the developer would be happy to take their patch."? Certainly. I was having difficulty determining how this status would be useful to non-distribution projects, but think you've described an excellent use case. Thank you. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: On Launchpad Bug Status values
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emmet Hikory wrote: > A month ago, an official list of Bug status values was published > on launchpad [1]. Without a discussion of the appropriate > classification of the various statuses that are used to track bugs > that may someday be fixed, I would like to hear if other MOTUs would > find an additional rejection status would be useful, defined as > follows: > > "Deferred" > > This status indicates that while this bug is valid, and there is > sufficient information to understand the cause, there is no current > intention to fix the problem by the project against which the bug is > reported. Deferred is meant to capture the cases where a reporter's > request is unlikely to be addressed in the project, and the reporter > would do well to pursue other channels in parallel. > > "Deferred" is distinct from "Invalid" in that an "Invalid" bug > represents a case where a bug doesn't represent something that can be > fixed, whereas "Deferred" bugs could be fixed, but nobody is going to > do it. > > "Deferred" is distinct from "Won't Fix" in that "Won't Fix" represents > a case where either the perceived problem or recommended solution is > contrary to the plans of the project, or the scope of the issue is > beyond the ability of the project to complet, whereas "Deferred" bugs > represent soluable issues. > Could this status also be used for cases of "This is a legitimate bug, but the project developer does not have the knowledge necessary to fix it at this time. You may need to wait a while until they do, or it may be more efficient to offer a bounty to someone else, in which case the developer would be happy to take their patch."? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHI9tzKlAIzV4ebxoRAq4fAJ4v+vpauO9fezLntJZy9qXPlNJ9XACeMfLj B2TMOuoseLYbYCJU5iOEctU= =tz0z -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
On Launchpad Bug Status values
A month ago, an official list of Bug status values was published on launchpad [1]. Without a discussion of the appropriate classification of the various statuses that are used to track bugs that may someday be fixed, I would like to hear if other MOTUs would find an additional rejection status would be useful, defined as follows: "Deferred" This status indicates that while this bug is valid, and there is sufficient information to understand the cause, there is no current intention to fix the problem by the project against which the bug is reported. Deferred is meant to capture the cases where a reporter's request is unlikely to be addressed in the project, and the reporter would do well to pursue other channels in parallel. "Deferred" is distinct from "Invalid" in that an "Invalid" bug represents a case where a bug doesn't represent something that can be fixed, whereas "Deferred" bugs could be fixed, but nobody is going to do it. "Deferred" is distinct from "Won't Fix" in that "Won't Fix" represents a case where either the perceived problem or recommended solution is contrary to the plans of the project, or the scope of the issue is beyond the ability of the project to complet, whereas "Deferred" bugs represent soluable issues. "Deferred" would typically only be useful to projects that distrbute a collection of software, including contributions from many other sources (such as a distribution (e.g. Ubuntu)), but would be used to specifically notify reporters that while such a problem exists, it will likely be solved more quickly upstream, while still indicating to interested parties investigating the bug database that code to provide such a solution would not be unwelcome. "Deferred" should be hidden from the default buglists (as "Won't Fix"), and there should be two automated status adjustments associated, as follows: 1) If there is a registered upstream task, and the upstream task acquires a status mapped to "Won't Fix", the "Deferred" task should be transitioned to "Won't Fix", as it is not appropriate to fix at a distribution level when upstream has already rejected it. 2) If there is another registered task (upstream or not), and that task acquires a status mapped to "Fix Committed" or "Fix Released", the "Deferred" task should be transitioned to "Triaged" to indicate there is an available solution, and someone should investigate integration. The primary goals in adding "Deferred" in addition to "Won't Fix" are 1) to encourage parites browsing the buglist who are interested and capable to contribute code, but also indicates that it is neither a priority nor likely to be committed without review by the project; and 2) to ensure that when fixes to these issues become available (either upstream or in another distribution), they are again raised for attention in Ubuntu. Without this status, many bugs are marked "Won't Fix", as Ubuntu doesn't have the resources or attention, and yet are later fixed, which doesn't seem to be the best feedback to submitters. I'd like to hear others opinions as to the utility of this proposed status. If there is consensus, I intend on coordinating with the MOTU launchpad liaison to request inclusion in a future release. 1: http://news.launchpad.net/general/of-bugs-and-statuses -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Forward porting gutsy-proposed uploads to Hardy
On Sat, 27 Oct 2007 22:06:51 +0200 Cesare Tirabassi <[EMAIL PROTECTED]> wrote: >On Saturday 27 October 2007 21:26:48 Michael Bienia wrote: >> On 2007-10-23 18:05:31 +0200, Michael Bienia wrote: >> > On 2007-10-23 10:19:51 -0400, Scott Kitterman wrote: >> > > As promised when we decided to go ahead with uploads to gutsy-proposed >> > > before hardy was open, here is the list of uploads that need to go into >> > > Hardy to catch up. Please reply to this message to the list when >> > > you've uploaded to hardy so it'll be easy to track. >> > >> > Source: gtk2hs >> >> Sync requested of gtk2hs 0.9.12-1 from Debian unstable. It contains the >> patch which is included in -proposed. >> Bug #157853: https://bugs.launchpad.net/bugs/157853 >> >> Michael > >Thanks for the head-up, I had totally forgotten we needed to report it: > >bug for which -proposed was issued >Bug #64032: https://bugs.launchpad.net/ubuntu/gutsy/+bug/64032 > >new version uploaded in hardy >https://lists.ubuntu.com/archives/hardy-changes/2007-October/65.html > >Cesare Great. IIRC there were two more... Anyone? Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Forward porting gutsy-proposed uploads to Hardy
On Saturday 27 October 2007 21:26:48 Michael Bienia wrote: > On 2007-10-23 18:05:31 +0200, Michael Bienia wrote: > > On 2007-10-23 10:19:51 -0400, Scott Kitterman wrote: > > > As promised when we decided to go ahead with uploads to gutsy-proposed > > > before hardy was open, here is the list of uploads that need to go into > > > Hardy to catch up. Please reply to this message to the list when > > > you've uploaded to hardy so it'll be easy to track. > > > > Source: gtk2hs > > Sync requested of gtk2hs 0.9.12-1 from Debian unstable. It contains the > patch which is included in -proposed. > Bug #157853: https://bugs.launchpad.net/bugs/157853 > > Michael Thanks for the head-up, I had totally forgotten we needed to report it: bug for which -proposed was issued Bug #64032: https://bugs.launchpad.net/ubuntu/gutsy/+bug/64032 new version uploaded in hardy https://lists.ubuntu.com/archives/hardy-changes/2007-October/65.html Cesare -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
StableReleaseUpdates - usplash-theme-ubuntustudio 0.15.1 ready for testing.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 An updated version of usplash-theme-ubuntustudio is available in gutsy-proposed. To test it, add the following line to your /etc/apt/sources.list file: deb http://archive.ubuntu.com/ubuntu/ gutsy-proposed universe The current package in gutsy fails to display any text, which needs to be visible for such prompts as passphrase entry for encrypted partitions. Please give feedback to the following bug, to confirm that text can be displayed on the splash screen, in some way or another: https://bugs.launchpad.net/bugs/155130 - - -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email & MSN: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHI5J+jVefwtBjIM4RAhe1AKDlsolnv+KQ+6USUO/JNu0ojXB9zwCg4H+d ASJfpOhx3n2YfS47phMbfWQ= =Ya3d -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Forward porting gutsy-proposed uploads to Hardy
On 2007-10-23 18:05:31 +0200, Michael Bienia wrote: > On 2007-10-23 10:19:51 -0400, Scott Kitterman wrote: > > As promised when we decided to go ahead with uploads to gutsy-proposed > > before > > hardy was open, here is the list of uploads that need to go into Hardy to > > catch up. Please reply to this message to the list when you've uploaded to > > hardy so it'll be easy to track. > Source: gtk2hs Sync requested of gtk2hs 0.9.12-1 from Debian unstable. It contains the patch which is included in -proposed. Bug #157853: https://bugs.launchpad.net/bugs/157853 Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Sitting out for Hardy
Most of you probably already know this from IRC, but ... I don't plan on much involvement during the Hardy developement cycle. MOTU has gotten to stressful for me for the stress to be worth the enjoyment I get out of it. There are a number of reasons that I hope that by sharing, I can hope make things better for everyone. 1. It seems like we've quickly evolved from the idea of people are expected to generally know what they are doing, think things through, and quickly fix mistakes when they are made to the idea that it's not wrong to do anything that isn't explicitly prohibited in some documentation. This rules oriented mindset makes it harder to get stuff done, harder to get mistakes corrected, and is, IMO, either the effect or a cause of an increasing level of defensiveness and reaction in the community. I think it works better to expect that people won't do things they don't know enough about (ask first) and fix stuff when they mess up. Having to have a written rule that SRUs should be tested before uploading is bizarre. 2. Both our processes and our tools (I'm thinking LP here) are evolving in ways that from my perspective make work harder, not easier. Tools and processes should support work getting done and I think things are not evolving for the better. 3. The seeming limitless tolerance for people to come back again and again with disruptive, incorrect advice, bugs, proposed uploads that has at times been an effective denial of service attack on MOTU. I can't work in this environment. People need time to learn, but there's a point beyond which they need to learn not to do damage and cause trouble for other people. During Hardy, I will not be reviewing sponsored uploads (I've subscribed from the motu-reviewers list on tauware.de and deactivated myself from UUS). I won't take on any 'management' roles like motu-uvf. I will still mind the packages I've been minding. I will still hang out on IRC (unless the atmosphere just gets too stressful for me) and help answer questions and be part of the community. I will also work on helping (not leading or doing) with things that can improve the problems that have led me to sit this one out. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
there is a bug with ubuntu 7.10 (gutsy gibbon) amd64 release of ecasound . Was working in 7.04
Hi, I assume this concerns mainly ubuntu packagers, but I also send it to ecasound-list since it probably will be of interest for other x86_64 users of ecasound. Something is broken in the gutsy version of ecasound, which was working in feisty. The level analyze option -ev does not work. [EMAIL PROTECTED] nice /usr/bin/ecasound -i test.wav -o:null -ev *ecasound v2.4.5 (C) 1997-2006 Kai Vehmanen and others - [ Session created ] -- - [ Chainsetup created (cmdline) ] - - [ Connecting chainsetup ] (eca-chainsetup) 'nonrt' buffering mode selected. (eca-chainsetup) Audio object "test.wav", mode "read". (audio-io) Format: s24_le, channels 2, srate 44100, interleaved. (eca-chainsetup) Audio object "null", mode "read/write". (audio-io) Format: s16_le, channels 2, srate 44100, interleaved. - [ Chainsetup connected ] - (eca-control-objects) Connected chainsetup: "command-line-setup". - [ Controller/Starting batch processing ] - - [ Engine init - Driver start ] --- - [ Controller/Batch processing finished (0) ] - (eca-control-objects) Disconnecting chainsetup: "command-line-setup". - [ Chainsetup disconnected ] -- A fresh compile does work, however [EMAIL PROTECTED] nice /usr/local/bin/ecasound -i test.wav -o:null -ev *ecasound v2.4.6.1 (C) 1997-2007 Kai Vehmanen and others - [ Session created ] -- - [ Chainsetup created (cmdline) ] - - [ Connecting chainsetup ] (eca-chainsetup) 'nonrt' buffering mode selected. (eca-chainsetup) Audio object "test.wav", mode "read". (audio-io) Format: s24_le, channels 2, srate 44100, interleaved. (eca-chainsetup) Audio object "null", mode "read/write". (audio-io) Format: s16_le, channels 2, srate 44100, interleaved. - [ Chainsetup connected ] - (eca-control-objects) Connected chainsetup: "command-line-setup". - [ Controller/Starting batch processing ] - - [ Engine init - Driver start ] --- - [ Controller/Batch processing finished (0) ] - (eca-control-objects) Disconnecting chainsetup: "command-line-setup". - [ Chainsetup disconnected ] -- (eca-chain) (audiofx) -- Amplitude statistics ... - Range, pos/neg, count,(%), ch1...n Pos -1.0 dB: 0,0.000%0,0.000% Pos -2.0 dB: 0,0.000%0,0.000% Pos -4.0 dB: 192,0.001% 0,0.000% Pos -8.0 dB: 17533,0.096%205,0.001% Pos -16.0 dB:472353,2.592% 260253,1.428% Pos -32.0 dB:3970401,21.790% 3362166,18.452% Pos -64.0 dB:4118029,22.600% 4764108,26.146% Pos -inf.0 dB: 550836,3.023% 693050,3.804% Neg -inf.0 dB: 541150,2.970% 688399,3.778% Neg -64.0 dB:4132686,22.681% 4794784,26.315% Neg -32.0 dB:3922807,21.529% 3399841,18.659% Neg -16.0 dB:473041,2.596% 258033,1.416% Neg -8.0 dB: 20969,0.115%217,0.001% Neg -4.0 dB: 1016,0.006% 0,0.000% Neg -2.0 dB: 36,0.000% 0,0.000% Neg -1.0 dB: 7,0.000%0,0.000% (audiofx) Peak amplitude, period: pos=0.69774 neg=0.91714. (audiofx) Peak amplitude, all : pos=0.69774 neg=0.91714. (audiofx) Clipped samples, period: pos=0 neg=0. (audiofx) Clipped samples, all : pos=0 neg=0. (audiofx) Max gain without clipping, all: 1.09035. (audiofx) -- End of statistics [EMAIL PROTECTED] Environment [EMAIL PROTECTED] uname -a Linux eponyme 2.6.22-14-generic #1 SMP Sun Oct 14 21:45:15 GMT 2007 x86_64 GNU/Linux [EMAIL PROTECTED] dpkg -l|grep ecasound ii ecasound 2.4.5-7 Multitrack-capable audio recorder and effect
