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?
Are you also suggesting that the "bug DAG" be a git repo separate from the source repo? 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? Your bugseverywhere.org link seems to cover most of my suggestions (except certain LP-specific ones). On Sat, Aug 6, 2016 at 4:23 AM, Ralf Hemmecke <r...@hemmecke.org> wrote: > On 08/06/2016 02:51 AM, Tim Daly wrote: > > Fixed bugs seem uninteresting. Several things failed on my car, for > > instance, that were fixed. There is rarely the need to revisit > > failures, except possibly in regression tests, like brakes :-) > > I don't understand your comment. You are in favour of even writing a > book about the bugs in AXIOM and complain about documenting fixed bugs? > Do I misunderstand something? > > > Except for release notes, why would anyone want to know about fixed > > bugs? At most someone running an old version might want to know. > > Not everyone is always up-to-date with the latest version of the > program. Of course, it would be good if developers can tell of a > misbehaviour of the program is because of the old version and that the > bug is already fixed in a newer version. > > Furthermore, a bugfix is not always a bugfix. It might fix the > misbehaviour, but at the same time introduce another misbehaviour, > because the bugfixer did not completely understand that part of the > program. Then it would be good for the next developer (or even for the > same developer---since people tend to forget) to know the underlying > assumptions for the old bugfix. > > > On the other hand, a known bug is an intrinsic part of the system > > (mis-)behavior and is something worth noting. Why would you want to > > keep that in, say github? > > If you understood my argument, I actually have nothing against putting > bugs into the same repo, but my suggestion is more that they live on a > disconnected DAG and not directly in the DAG of the source code commits. > I think bugs have a different life cycle than source code. > > > Axiom has a git repo at savannah, sourceforge, and axiom-developer. > > Which of these should be "the master bug list?". > > As with git, one has to declare one to be the master repo. It's only a > small thing to declare one bugtracker as the master. And if the > bugtracker would manage the bugs via git in a separate DAG, then one > could also have the bugs offline. It would probably a bit of a problem > to merge different (half-on/half-offline) discussion lines about a bug, > but I consider that a problem of the specific bugtracker tool. > Unfortunately, I haven't seen a nice and easy to use bugtracker with > underlying git. > > > It is mildly surprising that the tools to maintain repos (e.g. git) > > don't have "git bugnote" or some such support built in. Or at least > > a "git bugfetch" to get the current bug list. > > True. I think that https://git-scm.com/docs/git-notes is also not the > right thing. > > Maybe http://bugseverywhere.org/ is close to what I have in mind, but > I've never tried it and it looks unmaintained (same for ticgit-ng > https://github.com/jeffWelling/ticgit). > > Ralf >
_______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org https://lists.nongnu.org/mailman/listinfo/axiom-developer
