Re: Re: How you can help

[Manish <mailtomanish.sharma@gmail.com>]

  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