Re: [Axiom-developer] Axiom project goals

[Tim Daly]

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.

https://github.com/joeyh/github-backup 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
"democracy".