From: Manish <mailtomanish.sharma@gmail.com>
To: Richard Riley <rileyrgdev@googlemail.com>
Cc: Bernt Hansen <bernt@norang.ca>,
emacs-orgmode@gnu.org, Ben Alexander <bva@alexanderonline.org>
Subject: Re: Re: How you can help
Date: Fri, 24 Oct 2008 21:57:07 +0530 [thread overview]
Message-ID: <e7cdbe30810240927p51634ad4g925a85dfbd4268c3@mail.gmail.com> (raw)
In-Reply-To: <okej262nu2.fsf@development.richardriley.net>
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
next prev parent reply other threads:[~2008-10-24 16:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-23 12:04 How you can help Ben Alexander
2008-10-23 13:43 ` Bernt Hansen
2008-10-23 15:04 ` Sebastian Rose
2008-10-23 15:49 ` Richard Riley
2008-10-23 16:22 ` Ben Alexander
2008-10-23 17:02 ` Sebastian Rose
2008-10-24 12:13 ` Richard Riley
2008-10-24 15:39 ` Sebastian Rose
2008-10-24 16:27 ` Manish [this message]
2008-10-24 18:41 ` Avdi Grimm
2008-10-23 19:13 ` Avdi Grimm
2008-10-24 12:19 ` Richard Riley
2008-10-23 16:19 ` Bernt Hansen
2008-10-24 5:05 ` Carsten Dominik
2008-10-23 17:01 ` Jason F. McBrayer
2008-10-23 23:46 ` Eric Schulte
2008-10-23 14:20 ` Sebastian Rose
2008-10-23 14:50 ` Manish
2008-10-23 15:46 ` Eric Schulte
2008-10-23 16:18 ` Avdi Grimm
2008-10-23 14:55 ` Ben Alexander
2008-10-23 16:26 ` Sebastian Rose
2008-10-23 16:42 ` Avdi Grimm
2008-10-23 17:33 ` Sebastian Rose
2008-10-23 19:10 ` Avdi Grimm
2008-10-24 21:09 ` Tom Breton (Tehom)
2008-10-24 18:33 ` Ben Alexander
2008-10-24 18:44 ` Avdi Grimm
2008-10-24 19:02 ` Jeff Mickey
2008-10-26 19:49 ` org-cycle broken when cursor is at ellipses Ben Alexander
2008-10-26 21:31 ` Cameron Horsburgh
2008-10-27 8:47 ` Carsten Dominik
2008-10-27 8:47 ` Carsten Dominik
[not found] ` <D43ED86C-EFD4-4BA8-8528-4F82DB11D625@alexanderonline.org>
2008-10-23 17:12 ` How you can help Sebastian Rose
2008-10-23 15:08 ` Sebastian Rose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e7cdbe30810240927p51634ad4g925a85dfbd4268c3@mail.gmail.com \
--to=mailtomanish.sharma@gmail.com \
--cc=bernt@norang.ca \
--cc=bva@alexanderonline.org \
--cc=emacs-orgmode@gnu.org \
--cc=rileyrgdev@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).