On Fri, Sep 28, 2012 at 8:40 AM, Luis Henriques <luis.henriq...@canonical.com> wrote: > If verification is not done by one week from today, this fix will be > dropped from the source code, and this bug will be closed.
This is yet another example of Ubuntu's absolutely horrid bug handling practices. Here we have a bug that has been verified to exist by multiple people, including the developer himself. The bug can cause a filesystem to fill up completely, which causes all sorts of software to fail, including causing programs to fail to exit, fail to save preferences, fail to save user data (DATA LOSS), and even interfere with logging out and shutting down the system, which is necessary to restore the free space. The developer has not only confirmed the bug, but has patched it and released a patch upstream. Now the patch is ready to be tested for release in the LONG TERM SUPPORT release, so that this LTS release might actually BE a dependable release. And what happens next? Non-specific people interested in the fixing of the bug are virtually threatened with extortion! I have very little free time right now to devote to reporting and following up on and testing bugs. It may be one or two or even more weeks between times that I am able to go through my bug-related emails. I could easily not even notice this message until the time had expired! This bug is of CRITICAL importance. But what happens if no one is able to test it in this arbitrary time limit? The fix will be dropped, and THE BUG WILL BE CLOSED! CLOSED! This is a CONFIRMED bug with SERIOUS consequences, and it will be CLOSED as if it were fixed! There is absolutely NO EXCUSE for this unconscionable behavior. 1. A one-week time limit is not enough. There are plenty of reasons why a fix like this might not be tested that quickly. 2. If the time limit does expire, it should be trivial to reopen the testing process. 3. Whether or not anyone EVER tests the fix and reports on it, a bug should NEVER, EVER be closed until it is FIXED! This goes DOUBLE for bugs like this of CRITICAL IMPORTANCE! What is Ubuntu thinking? "Oh well, no one has tested the fix yet, and I'm too impatient to wait, so it must not matter anymore. Let's just pretend it never happened, and we can all go on working in ignorant bliss." I don't know what the motivation behind this policy is, but that's the way it comes off to people who spend their VALUABLE TIME helping to investigate and fix bugs like this. And regardless of the motivation, it is completely unreasonable. I have said it so many times, and I will say it again: Ubuntu should learn from Debian. Bugs in Debian are never, ever closed unless they're truly fixed or the software is removed from the archive. A bug might remain open for years, but until it's fixed, it is documented and remains "open" for others to reference. Debian is honest; Debian has integrity; Debian values truth over statistics and convenience. Debian does not disparage the contributions of its users--unlike Ubuntu, which makes unreasonable threats such as this, while saying "Thank you for helping to make Ubuntu better" out of the other side of its mouth. Again, I don't know about Mr. Henriques's stance on this issue, but what matters in the end is the result. The result is that 1) users are discouraged from participating and helping; 2) the quality of Ubuntu continues to decline; 3) real, serious bugs go unfixed, causing real people to suffer real consequences. What's ironic is that policies such as this are matters of decision-making and leadership, and Ubuntu is far more structured than Debian--yet Debian is the one leading the way with sensible, transparent policies. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/561129 Title: Existing eCryptfs inodes are not evicted when they're the target of a rename()/mv To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/561129/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
