From: Sebastian Rose <sebastian_rose@gmx.de>
To: emacs-orgmode@gnu.org
Subject: Re: Re: worg for bug reports and feature requests was: (Regression testing for org-mode)
Date: Fri, 24 Oct 2008 16:12:51 +0200 [thread overview]
Message-ID: <4901D7E3.1060809@gmx.de> (raw)
In-Reply-To: <49015239.1020008@sift.info>
While full fletched bug tracker is a _very_ usefull tool for developers,
it's a drag for users.
As for the users, I'm not shure if we should urge them to use a bug
tracking system at all. The list works so fine and natural. It's
is quite low/medium traffic with those bug reports.
As Richard Riley statud lately, it often turns out, that the 'bug'
boiles down to some configuration problem. Lots of testing is done by
the users, simply by using org. Since we still don't have a complete set
of automated tests, this will be the case for quite some time.
And, the list is, what everyone reads. Sometimes new people show up,
read about a bug and provide patches. Why 'hide' the bugs somewhere?
That said, I still believe a bug tracker as an 'internal' tool for the
testers/developers would be of _great_ help.
IMO, it would definitively make sense to use bugzilla or track
for that. I don't want to implement all those features from scratch,
that make a bug tracker usefull.
Where will such a system live?
Who installs and maintains it?
Robert Goldman wrote:
> Eric Schulte wrote:
>> Robert Goldman <rpgoldman@sift.info> writes:
>>
>>> Avdi Grimm wrote:
>>>> On Thu, Oct 23, 2008 at 7:57 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>>>>> Also, should we start tracking bug reports somewhere (worg), so that
>>>>> they can be claimed, tested against, and repaired?
>>>> Not a bad idea. Normally I'd recommend just going with an established
>>>> bug tracker like Trac or Lighthouse, but since Org is so great for
>>>> managing tasks it seems only right that the developers should "eat
>>>> their own dogfood" by using Org to track tickets :-)
>>>>
>>> Actually, I'm not sure I necessarily agree with the notion of using Org
>>> to track tickets. The reason is not that org mightn't be up to the job,
>>> but that the use of org with git won't be up to it. systems like trac
>>> and bugzilla are set up to allow outsiders to post bugs, but if we use
>>> git, then we're really raising the bar for bug submission. Instead of
>>> filling out a form, a bug reporter would now have to figure out how to
>>> use git, pull the org file, modify it, and then either push it (which
>>> would require someone to authorize him or her) or submit it to someone
>>> else who would push it. That seems inappropriate to me --- when you're
>>> developing software a good bug report is very valuable, and one
>>> shouldn't turn them away.
>>>
>>> Unless someone can figure out an easier way for people to submit bugs
>>> with what worg has now, I'm inclined to say that trac or bugzilla would
>>> be better.
>>>
>> Yes, you're correct the current method of contributing to worg is
>> definitely too high of a bar for bug reports, or feature requests. That
>> said once they were submitted, worg would be a good mechanism for
>> tracking reported bugs/features, and for publishing lists of said
>> reports on the web. Worg/org has the added advantage that it is already
>> familiar to the entire org community.
>>
>> As you mention, the question seem to be: can we implement a simple
>> interface for reporting bugs/feature-recs which will?
>>
>> 1) work well with worg as it's currently used, and
>> 2) which won't constantly be begging for enhancements until we're
>> re-implementing a full bug tracking system from scratch
>>
>> I don't think this would be too difficult, say...
>>
>> a simple web form, which could be embedded into one of the worg pages,
>> and could drop bug/feature-recs into an org-mode file under git.
>> Would anyone be up to trying to throw such a thing together? If only
>> I had some more time...
>>
>
>
>
> I don't mean to seem like a party-pooper, but I would suggest that we
> not do this. Getting even the simple web form done right involves
> thinking hard about dealing with spam bots, people trying to hack your
> site, etc. The people who built bugzilla and trac (and apache) have a
> lot more experience with this kind of issue than we do (at least
> speaking for myself), and have had a lot of time to shake the kinks out.
> If you want a real ticket system, I'd suggest using one of these rather
> than rolling another one.
next prev parent reply other threads:[~2008-10-24 14:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-23 16:03 Regression testing for org-mode Robert Goldman
2008-10-23 23:57 ` Eric Schulte
2008-10-24 0:03 ` Avdi Grimm
2008-10-24 2:41 ` Robert Goldman
2008-10-24 3:04 ` worg for bug reports and feature requests was: (Regression testing for org-mode) Eric Schulte
2008-10-24 4:42 ` Robert Goldman
2008-10-24 14:12 ` Sebastian Rose [this message]
2008-10-24 14:27 ` Avdi Grimm
2008-10-24 20:44 ` Eric Schulte
2008-10-24 23:54 ` Eric Schulte
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=4901D7E3.1060809@gmx.de \
--to=sebastian_rose@gmx.de \
--cc=emacs-orgmode@gnu.org \
/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).