From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manish Subject: Re: Re: How you can help Date: Fri, 24 Oct 2008 21:57:07 +0530 Message-ID: References: <967CE7ED-05E9-4031-9F3B-CFB826511554@alexanderonline.org> <878wsfpgtp.fsf@gollum.intra.norang.ca> <877i7zbbe4.fsf@kassiopeya.MSHEIMNETZ> <87iqrj9rdl.fsf@kassiopeya.MSHEIMNETZ> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtPVJ-0008QX-0Q for emacs-orgmode@gnu.org; Fri, 24 Oct 2008 12:27:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtPVH-0008QG-9O for emacs-orgmode@gnu.org; Fri, 24 Oct 2008 12:27:12 -0400 Received: from [199.232.76.173] (port=35796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtPVH-0008QD-6X for emacs-orgmode@gnu.org; Fri, 24 Oct 2008 12:27:11 -0400 Received: from ti-out-0910.google.com ([209.85.142.188]:26059) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtPVH-0006Qr-5c for emacs-orgmode@gnu.org; Fri, 24 Oct 2008 12:27:11 -0400 Received: by ti-out-0910.google.com with SMTP id u5so592974tia.10 for ; Fri, 24 Oct 2008 09:27:07 -0700 (PDT) In-Reply-To: Content-Disposition: inline List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Richard Riley Cc: Bernt Hansen , emacs-orgmode@gnu.org, Ben Alexander On Fri, Oct 24, 2008 at 5:43 PM, Richard Riley wrote: [snip] > I think the best thing people can do is keep a stable version and also > test the CVS (oops) GIT version too very now and again. +1 That's exactly what I try to do. I update almost every other day, go through (using tig) the diffs of code, changelog, documentation, comments.. and see if I can try out and learn something. I also try and report if something doesn't work right for me with whatever details I can provide. It really doesn't take too long. I definitely need to learn more about generating backtraces and debuggers so I could do a better job at providing right kind and level of details. With the kind of people we have on the list, we already have a high quallity Volunteer Powered Massively Parallel Testing System - VPMPTS (tm) in place. :) Let me take a step back and think aloud why we need a bug-tracking and testing system (if only to clarify my understanding) and who/when does it help. Following scenarios come to mind (and how they can be handled best (again only my limited understanding)): 1. Someone sees something odd, assumes it's a bug and wants/needs to report it. Report it to list, people will help out if it's a configuration or understanding issue or confirm if it's a repeatble issue. 2. A bug report needs to be confirmed. VPMPTS goes to work. :) 3. A bug needs to be communicated to the developers. Developers look at the bug confirmation reports on the list and decide whether to accept it as a bug or improve our collective understanding. 4. New functionality needs to be tested for regression. VPMPTS to rescue! 5. Bug reporter needs to know when the bug is fixed. Read the list! (Possibly track git repo as well.) 6. Developers needs to sync up about who is working on a specific bug. Seems like bug tracker will be useful. This is for developers to comment upon but bug acknowledging developer can be safely assumed to know the reasons behind the bug and assumed to own it. I confess I do not have programming or testing background so I may be completely out of whack here. IMHO, we should go in the direction of taking on the overhead of maintaining additional infrastructure only when it's inevitable or really valuable. Let me take another step back and recall Carsten't first email on this thread; he asked for help in 5 specific areas: 1. Providing sufficient details when reporting bugs. 2. Reproducing reported bugs. 3. Sub-system adoption. 4. Answering emails on list. 5. Adding to Worg in form of FAQ, tutorials, and hacks. I think #1 needs a tutorial (at least for me.) We already do #2 and #4. #5 needs more work to cover as many features as possible (mea culpa.) #3 is up to elisp gurus here. I believe Carsten thought long and hard before he came up with this list of very specific areas which, IMHO, covers most (if not all) of the scenarios I conjured up above. >> >>> Do I think regression testing is important? Yes - in certain >>> environments. But every time Carsten, you, myself or anyone else fires >>> up org-mode we are already doing just that. >> >> Yes, but we can do better, easier and more complete. > > Possibly. I look forward to seeing proposed solutions and would gladly > lend some time to applying them. Ditto. Please do not assume that I am against any change in our systems and processes. I am just trying to see the system working in my mind's eye. -- Manish