rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 196 deletions

diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn
deleted file mode 100644
index 72bb3b77..00000000
--- a/open_issues/issue_tracking.mdwn
+++ /dev/null
@@ -1,196 +0,0 @@
-[[!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]]."]]"""]]
-
-[[!toc]]
-
-
-# Savannah Trackers, Open Issues, debbugs
-
-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.
-
-IRC, freenode, #hurd, 2011-10-19:
-
-    <antrik> tschwinge: BTW, what happened to the plan of killing help-hurd?
-    <antrik> (and possibly some other lists)
-    <tschwinge> antrik: That plan got stalled, obviously.  ;-)
-    <tschwinge> antrik: Now, I had proposed to use hurd-dev for development,
-      and turn bug-hurd into a debbugs bug reportling list.  That proposal has
-      not heard any supportive/unsupportive votes yet.
-    <tschwinge> hurd-devel.  That's the name.
-    <tschwinge> And turn off hurd-devel-readers.  And turn off help-hurd.
-    <tschwinge> And web-hurd.
-    <tschwinge> Keep l4-hurd.
-    <antrik> yeah, I haven't replied regarding bug-hurd vs. hurd-devel, as I'm
-      not quite sure myself
-    <antrik> on one hand, a dedicated bug list can be convenient; on the other
-      hand, this kind of splits always causes unnecessary overhead IMHO
-    <antrik> also, hurd-devel would obviously be *only* for development, so in
-      this scenario we actually would *need* to keep something like help-hurd
-      as well...
-    <antrik> I think I'd prefer the non-exclusive mode for debbugs... would
-      have to check again how it works exactly though :-)
-    <tschwinge> antrik: I quite liked that exclusive mode for it automatically
-      archives discussions grouped by threads for easy reference.
-    <tschwinge> antrik: And, the very most of bug-hurd emails are ``issues'' of
-      some sort: bug report, patch (that needs to be tracked until it is
-      applied, etc.
-    <antrik> tschwinge: exclusive mode would just mean that people would take
-      most of these discussion elsewhere, and the bug list would only be used
-      when someone explicitly wants something tracked as a bug...
-    <antrik> ideally, the bug tracker should only track things if explicitly
-      CCed. ideally, it should be possible to forward mails that have been
-      posted without CC, so they can be tracked retroactively...
-    <tschwinge> antrik: Why do you think that people would take discussions
-      elsewhere?
-    <antrik> because most people don't consider it useful to put every random
-      question or remark in an issue tracker
-    <antrik> IMHO it should be easy to turn messages into tickets/followups;
-      but it should not happen automatically
-    <tschwinge> What if people wouldn't even notice that their issues is kept
-      in a tracker, too?
-    <draculus> It might send a notification of some sort?
-    <antrik> I once posted to a list with RT in exclusive mode, and quite
-      frankly, I considered it rather strange to get a ticket created for my
-      message :-)
-    <antrik> tschwinge: that would only be useful if you always close tickets
-      for irrelevant or finished discussions, mark duplicates etc. -- and this
-      would have to happen silently, without noise for most other people
-      following the list...
-    <antrik> tschwinge: are you sure you want to do that?... :-)
-    <tschwinge> Yes.
-    <tschwinge> Because that way we don't lose so much stuff as we currently
-      do.
-    <antrik> well, the decision is up to you in that case...
-    <tschwinge> In fact, probably less than manually archiving the content, as
-      I'm doing now, partially.
-    <tschwinge> antrik: Well, I'm just out for getting some comments.
-    <antrik> it would further reduce our bus factor though :-(
-    <tschwinge> That already is low enough that it doesn't matter anymore...
-    <tschwinge> antrik: So, to sum up, you'd use non-exclusive mode, but are
-      not actively opposed to exclusive mode as long as it doesn't too much
-      disturbe any procedures you're currently using?
-    <antrik> well, if it happens mostly in the background, I don't see why
-      anyone should be opposed...
-    <antrik> just make sure people posting to the list don't get a "ticket
-      created" message in response :-)
-    <antrik> it would make it harder though for people to explicitly track
-      issue they are interested in I fear
-    <antrik> when using non-exclusive mode, and people explicitly CC things to
-      the tracker, which sends a notice about a ticket being created, everyone
-      sees that and can act accordingly. if everything happens in the
-      background, few people would even think about it...
-    <antrik> so non-exclusive mode probably needs more effort to keep in order;
-      but it would be more useful too...
-    <tschwinge> Well, but with exclusive mode, people don't lose anything
-      compared to the current state, do they?
-    <antrik> tschwinge: probably not compared to the current state... but
-      possibly compared to a well-used non-exclusive mode :-)
-
-
-# Further Systems
-
-  * ikiwiki
-
-      * <http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/>
-
-      * <http://ikiwiki.info/todo/Better_bug_tracking_support/>
-
-      * <http://ikiwiki.info/todo/tracking_bugs_with_dependencies/>
-
-      * <http://ikiwiki.info/todo/Updated_bug_tracking_example/>
-
-  * <http://bugseverywhere.org/>