[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Axiom project goals

From: Tim Daly
Subject: Re: [Axiom-developer] Axiom project goals
Date: Thu, 4 Aug 2016 16:17:41 -0400

In the spirit of the game I'm moving the buglist to be a full
literate volume, published like all the others. This will allow
automation, extraction and testing of various bugs
during build time and keep the bug list up to date and public.

I'm also re-ordering it so that the various bugs/warnings/etc
are grouped logically (e.g. interpreter, category, domain, etc)
rather than the prior "stack by most recent" orientation. That
will make it easier to find duplicates as well as simplify the
focus of any debugging effort.

This will be followed by a review of all outstanding bugs to
see if they are still valid.

There goes another few weeks.

On Mon, Aug 1, 2016 at 8:23 AM, oldk1331 <address@hidden> wrote:
To Ralf:

> So subscription is not a big issue, I think.

Once signin github, one can config to use email to reply to github
issues, instead of web interface.

> Do you have a more concret pointer? Would be nice to be able to
> automatically download and commit a new issue when it comes in from some
> user. Actually, I am somewhat sure that behind the scenes github already
> ehandles issues as git repositories internally. can backup github issues,
it's written in Haskell, and I haven't used it before.
For "automatically doing things", there are github APIs.
BTW, github wiki is a git repo itself.

To Tim:

> That said, it might help to realize that a bug report is a major time sink
> for a lead developer. People expect a fix, or at least a response, rather
> immediately. Often bug reports don't contain enough information to
> reproduce the bug. And, if you can reproduce it, you might not understand
> it enough to decide IF it is a bug. Responding to a bug report can cost at
> least one-half day.

The bug tacker not necessarily be a lead developer's thing, it's intend to
be community driven.  False bugs posted by novice users can be quickly
replied by more experienced users.  And details of the bug can be filled
when more and more users reply.

> More issues arise if a "fix" is posted. Does the fix compile? Not everyone
> does a full system build to check before posting. Does the fix actually
> fix the bug? Perhaps the bug is deeper than the surface fix. Is there a
> failing test case and does the fix 'fix' it?

There's a thing called CI (continuous integration), and it can be integrated
with github.

> Ideally there should be someone who is a "second-in-command" that
> handles things like bugs... but I can tell you from experience that
> a "second-in-command" can undermine a project from within and is
> a very risky decision.

If you have some experience with github bug tracker and its culture,
you will find bug tracker is actually a community thing, and very

reply via email to

[Prev in Thread] Current Thread [Next in Thread]