[Top][All Lists]

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

Re: [Axiom-developer] Under-appreciated aspects of literate programming

From: Tim Daly
Subject: Re: [Axiom-developer] Under-appreciated aspects of literate programming
Date: Sat, 6 Aug 2016 19:49:46 -0400

Hmmm. Your link distinguishes 3 cases, out-of-tree (such as
in a github bug tracker), off-branch (which appears to be what
you are suggesting, right?), and on-branch (part of the sources
in the Axiom scheme).

He raises the question of merging bugs where systems might
have custom software to do things like maintain state (fixed?
diagnosed? open?). In the abstract this is a simple task that
really doesn't need much automation. The github-style out-of-tree
systems seem to have the most (and incompatible) automation.

He also raises issues of distributed bug tracking where there are
multiple sites and/or multiple VCS. This tends to undermine
things like bug state since it is not universal. So any system
that is multiple sites/VCS such as Axiom runs into the state
problem. If there are 3 states on one site and 7 on another,
how are bugs classified?

He raises the problem of a GUI, potentially two versions,
one local and one remote. If there are multiple sites he raises
the distributed database issue. More code, more work, less gain.
Books don't need a GUI, just a PDF reader.

For most of its life Axiom stored bugs in the mailing list.

These were collected into a single "buglist" file a couple years
ago. The recent discussion caused a revisit of the buglist and
made it "first-class" as a literate source, enabling the features
I previously mentioned. Now it is a live object, not just a list of
bug reports and comments.

Axiom's literate version is "on-branch", uses no special state code,
and is "distributed" in that it can be used disconnected since
it is part of the source distribution. It is a single book so there
are no issues about DAGs or directories. Bugs can be attached
to sources (where the connection is known) using hyperlinks
between documents.Bugs can be automatically checked at
build time. I don't see all of these features in any of the DCVS
bug trackers he reviewed.

Everything in Axiom is moving to book form. For example,
Hyperdoc now fetches pages directly from the book, not from
a directory of files. Eventually everything will be in books.So
it makes sense that bugs are literate and cross-linked to the
source books.

Scraping through the forums for bugs is time consuming.
How to handle that collection seems to have many aspects.
Your link seems to have covered them well but he didn't seem
to converge on a solution.

On Sat, Aug 6, 2016 at 6:21 PM, Ralf Hemmecke <address@hidden> wrote:
On 08/06/2016 01:28 PM, Tim Daly wrote:
> Methinks I mis-understood your DAG suggestion.
> Are you suggesting that the source code is in one DAG
> (src/doc/build/etc) and that bugs are in a parallel DAG?

More or less yes. I think it is a bit like when you document a project
on github.

The gh-pages branch is disconnected from the source code (ie, there are
two DAGs, but they live in the same repository.

> Are you also suggesting that the "bug DAG" be a git repo
> separate from the source repo?

Of course, if that are disjoint DAGs, it's easy to make them live in
different repositories. But git allows to handle several disjoint DAGs
in one repository. (My Definition: A "repository" is simply a collection
of git-objects (and the pointers to form DAGs) under a common name).

> In a pile-of-sand (POS) project organized by a directory
> structure would it be just as easy to have a bugs directory
> in every sub-directory? That would seem to fulfill the goal
> but can git have overlapping git-managed directories?

I don't think that a bug directory in every sub-dir would make sense.
Bugs sometimes touch different parts of a program and usually the
submitter of the bug has no idea, in which part of program the bug might
be hidden.

Otherwise I don't understand "overlapping git-managed directories" to be
able to give a good answer.

> Your <> link seems to cover most of my
> suggestions (except certain LP-specific ones).

Well, that's what I found and what (I think) would be good, but read
There are lots of things to consider before one embarks on a particular
distributed bugtracker. Obviously, in contrast to distributed version
control systems, the world hasn't yet seen a great acceptance of
distributed bugtrackers.


reply via email to

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