open_issues/issue_tracking: New.

id:"20110831073825.GF8538@alien.local",
id:"87aaapyig0.fsf@kepler.schwinge.homeip.net", IRC.

1 files changed, 98 insertions, 0 deletions

diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn
new file mode 100644
index 00000000..6693413b
--- /dev/null
+++ b/open_issues/issue_tracking.mdwn
@@ -0,0 +1,98 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+There are the Savannah trackers.  Nobody really likes them.
+
+There is a proposal to add/move to <http://debbugs.gnu.org/>.  It can be
+operated by email, Debian people (developers and users) already know how to use
+it.
+
+There are the [[Open_Issues]] pages.  This is basically just free-form text
+enriched by some tags for grouping, editable via the web and through Git
+commit.  [[tschwinge]] added this to the set, and/but mostly is the sole user
+of it, even though casually there are a few other people contributing, and
+surely these pages do show up in web searches.  A more traditional system (like
+the Savannah trackers or the new debbugs) do have their advantages, too, so
+perhaps there's a niche for both these and the [[Open_Issues]].
+
+IRC, freenode, #hurd, 2011-08-31:
+
+    <tschwinge> So.  Savannah trackers vs. Open Issues vs. debbugs.  Any input?
+    <youpi> I like *both* open issues and debbugs
+    <youpi> open issues is good for exposing things that people may encounter
+      in other situations
+    <youpi> while debbugs is useful to actually work on a bug
+    <tschwinge> youpi: The advantage of debbugs being the email interface and
+      the well-known procedure, or something else?
+    <youpi> email interface, which nicely flows into a mailing list
+    <youpi> the savannah bug updates suffer from the additional layout
+    <tschwinge> How does one decide what to put in a debbug and what in an Open
+      Issue page?
+    <youpi> I'd say it's not exclusive at all
+    <youpi> like, a bug on a specific case can start as debbug, and as we
+      discover it's more general and will not be fixed immediately, get an open
+      issue page
+    <youpi> and conversely, when we know some shortcoming, start with an open
+      issue, and if some bugs are submitted which are actually due to it,
+      cross-link
+    <tschwinge> OK.
+    <youpi> (some general short coming I mean, like SIGINFO)
+    <tschwinge> And we would keep the current stuff in the trackers, and let
+      these ``get empty'' gradually (it'll be years...) ;-) or migrate the
+      remaining issues?
+    <tschwinge> What we can do is inhibiting the creation of new issues in the
+      trackers.
+    <youpi> I'd say move
+    <youpi> else they will be forgotten
+    <tschwinge> Hrm.
+    <antrik> actually, I considered creating a track-like plugin for ikiwiki,
+      as both the popularity of trac and the usefulness of open_issues show
+      that something wiki-like is actually more useful than a rigid traditional
+      bugtracker. but I'm not really willing to do the work, which is why I
+      didn't propose it before :-)
+    <antrik> err... trac-like
+    <youpi> yes, the wiki part is really useful to keep a good summary of the
+      issue
+    <tschwinge> antrik: Same for me.  I always hoped that someone would do
+      it...  :-)
+    <antrik> hehe
+    <tschwinge> antrik: But, as you surely know, this email parsing business is
+      just too ugly to do realiable, etc.
+    <antrik> youpi: my point is that adding a few additional bits (like a
+      comfortable tagging functionality, and some mail interface) could turn
+      into a full-blown tracker unifying the advantages of both... but as I
+      said, I'm not really willing to do the work :-)
+    <youpi> additional to open_issue you mean?
+    <youpi> yes, but like you say :)
+    <antrik> tschwinge: hm... seems to work well enough it debbugs
+    <youpi> debbugs just piles things
+    <youpi> and has a few commands
+    <youpi> you'd still need the web interface to edit the wiki part for
+      instance
+    <antrik> of course. that wouldn't change at all
+    <antrik> (except for adding a tagging GUI perhaps)
+    <antrik> (debbugs of course is not the only mail-operable bugtracking
+      system... there are a number of others -- and I heard rumors even
+      bugzilla grew a mail interface now...)
+    <youpi> antrik: a .mdwn diff should however be sent to the bug for
+      information
+    <youpi> atm, what happens sometimes is somebody saying something here on
+      #hurd, tschwinge turning that into an open_issue, and it does not show up
+      on the mailing list
+    <tschwinge> debbugs surely has the advantage that it is available (nearly)
+      right now.
+    <mattl> RT (request tracker) and ikiwiki play quite nicely together.
+    <tschwinge> mattl: You'Re using that at GNU/FSF/somewhere, right?
+    <mattl> you can close tickets from the wiki, and RT has a good command line
+      interface, email interface and web interface.
+    <mattl> tschwinge: yeah, we use RT and ikiwiki.
+    <mattl> RT for all FSF communications, and ikiwiki for internal organising.
+    <mattl> RT is not the easiest thing to set up, but works pretty well once
+      it's running.