From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- .../issue_tracking.mdwn | 196 --------------------- 1 file changed, 196 deletions(-) delete mode 100644 service_solahart_jakarta_selatan__082122541663/issue_tracking.mdwn (limited to 'service_solahart_jakarta_selatan__082122541663/issue_tracking.mdwn') diff --git a/service_solahart_jakarta_selatan__082122541663/issue_tracking.mdwn b/service_solahart_jakarta_selatan__082122541663/issue_tracking.mdwn deleted file mode 100644 index 72bb3b77..00000000 --- a/service_solahart_jakarta_selatan__082122541663/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 . 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: - - So. Savannah trackers vs. Open Issues vs. debbugs. Any input? - I like *both* open issues and debbugs - open issues is good for exposing things that people may encounter - in other situations - while debbugs is useful to actually work on a bug - youpi: The advantage of debbugs being the email interface and - the well-known procedure, or something else? - email interface, which nicely flows into a mailing list - the savannah bug updates suffer from the additional layout - How does one decide what to put in a debbug and what in an Open - Issue page? - I'd say it's not exclusive at all - 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 - 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 - OK. - (some general short coming I mean, like SIGINFO) - 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? - What we can do is inhibiting the creation of new issues in the - trackers. - I'd say move - else they will be forgotten - Hrm. - 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 :-) - err... trac-like - yes, the wiki part is really useful to keep a good summary of the - issue - antrik: Same for me. I always hoped that someone would do - it... :-) - hehe - antrik: But, as you surely know, this email parsing business is - just too ugly to do realiable, etc. - 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 :-) - additional to open_issue you mean? - yes, but like you say :) - tschwinge: hm... seems to work well enough it debbugs - debbugs just piles things - and has a few commands - you'd still need the web interface to edit the wiki part for - instance - of course. that wouldn't change at all - (except for adding a tagging GUI perhaps) - (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...) - antrik: a .mdwn diff should however be sent to the bug for - information - 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 - debbugs surely has the advantage that it is available (nearly) - right now. - RT (request tracker) and ikiwiki play quite nicely together. - mattl: You'Re using that at GNU/FSF/somewhere, right? - you can close tickets from the wiki, and RT has a good command line - interface, email interface and web interface. - tschwinge: yeah, we use RT and ikiwiki. - RT for all FSF communications, and ikiwiki for internal organising. - RT is not the easiest thing to set up, but works pretty well once - it's running. - -IRC, freenode, #hurd, 2011-10-19: - - tschwinge: BTW, what happened to the plan of killing help-hurd? - (and possibly some other lists) - antrik: That plan got stalled, obviously. ;-) - 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. - hurd-devel. That's the name. - And turn off hurd-devel-readers. And turn off help-hurd. - And web-hurd. - Keep l4-hurd. - yeah, I haven't replied regarding bug-hurd vs. hurd-devel, as I'm - not quite sure myself - on one hand, a dedicated bug list can be convenient; on the other - hand, this kind of splits always causes unnecessary overhead IMHO - 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... - I think I'd prefer the non-exclusive mode for debbugs... would - have to check again how it works exactly though :-) - antrik: I quite liked that exclusive mode for it automatically - archives discussions grouped by threads for easy reference. - 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. - 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... - 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... - antrik: Why do you think that people would take discussions - elsewhere? - because most people don't consider it useful to put every random - question or remark in an issue tracker - IMHO it should be easy to turn messages into tickets/followups; - but it should not happen automatically - What if people wouldn't even notice that their issues is kept - in a tracker, too? - It might send a notification of some sort? - 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 :-) - 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... - tschwinge: are you sure you want to do that?... :-) - Yes. - Because that way we don't lose so much stuff as we currently - do. - well, the decision is up to you in that case... - In fact, probably less than manually archiving the content, as - I'm doing now, partially. - antrik: Well, I'm just out for getting some comments. - it would further reduce our bus factor though :-( - That already is low enough that it doesn't matter anymore... - 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? - well, if it happens mostly in the background, I don't see why - anyone should be opposed... - just make sure people posting to the list don't get a "ticket - created" message in response :-) - it would make it harder though for people to explicitly track - issue they are interested in I fear - 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... - so non-exclusive mode probably needs more effort to keep in order; - but it would be more useful too... - Well, but with exclusive mode, people don't lose anything - compared to the current state, do they? - tschwinge: probably not compared to the current state... but - possibly compared to a well-used non-exclusive mode :-) - - -# Further Systems - - * ikiwiki - - * - - * - - * - - * - - * -- cgit v1.2.3