From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Vong Subject: Re: Feedback, ideas, discussion: tracking patches, discussions, bugs. Date: Fri, 02 Sep 2016 18:54:47 +0800 Message-ID: <878tvafu6g.fsf@gmail.com> References: <57B1AD4D.2080907@goebel-consult.de> <20160815153059.7c8201e6@scratchpost.org> <87h9am5aco.fsf@gmail.com> <57B2BEDA.2020202@goebel-consult.de> <874m6kbyg4.fsf@gmail.com> <57B5A049.6070206@goebel-consult.de> <87wpiwruyd.fsf@we.make.ritual.n0.is> <87inuf27h7.fsf@we.make.ritual.n0.is> <20160902002755.GA30382@jocasta.intra> <87vayfm821.fsf@we.make.ritual.n0.is> <8737liam03.fsf@gmail.com> <87shtiogoq.fsf@we.make.ritual.n0.is> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfm7h-0004jJ-R7 for guix-devel@gnu.org; Fri, 02 Sep 2016 06:55:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfm7c-00081w-LT for guix-devel@gnu.org; Fri, 02 Sep 2016 06:55:00 -0400 Received: from mail-pa0-x229.google.com ([2607:f8b0:400e:c03::229]:36579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfm7c-00081s-66 for guix-devel@gnu.org; Fri, 02 Sep 2016 06:54:56 -0400 Received: by mail-pa0-x229.google.com with SMTP id fu3so31714477pad.3 for ; Fri, 02 Sep 2016 03:54:55 -0700 (PDT) In-Reply-To: <87shtiogoq.fsf@we.make.ritual.n0.is> (ng0@n0.is's message of "Fri, 02 Sep 2016 08:21:25 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: ng0 Cc: guix-devel@gnu.org ng0 writes: > Alex Vong writes: > >> Hi, >> >> >> I think I share the same concern as you do, currently the mailing list >> is too crowded and it is difficult to find the relevant bit. Below are >> my opinions on it: >> >> >> While it may not be as user-friendly as web-based bug tracker these >> days, I think the Debian bug tracking system is still better than our >> current approach. In Debian, everything is a package. It is like a >> language primitive in the bug tracker system. >> >> >> There is an "intended to package" (ITP) package. When you want to >> package something, you simply file a bug against the ITP package. This >> has the advantage that, the relevant information stays within the bug >> report. So everyone can see the whole process, starting from someone >> intending to package, to a fully reviewed package, all in a single bug >> report. It is like having "lexical scoping". >> >> >> And the most important argument comes: We already have it now[0]! So, >> this could be a working intermediate solution. Currently, we are not >> using debbugs to its full potential. >> >> >> My suggestion will be to create a new package called "guix-package", and >> all people hoping to introduce a new package to guix should file a bug >> report to . If you are new to this type of bug >> tracking system, no problem! There is (some) documentation on it[1][2] >> and here is my own little example[3]. >> >> >> Hope this make sence! >> >> >> Cheers, >> Alex >> >> >> [0]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix >> [1]: https://debbugs.gnu.org/Reporting.html >> [2]: https://debbugs.gnu.org/server-control.html >> [3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24352 > > Interesting, this is close to the Gentoo system: Everything is a bug. > Which means, every update, every bug, every new package, every "our > infrastructure server XYZ broke" request, etc. > > In a recent bug report through debbugs at Guix side I was not able to > figure out how to close the bug at all. I think if this isn't covered > good enough in upstream docs, we should 1. point it out at our side and > then 2. improve upstream documentation as the email sent when you open > the bug should state how you close the bug again.. > I'll report this bug upstream and try to fix it if it's hasn't caught > their attention and it still exists - maybe gnu.org version just happens > to be outdated. > Indeed, documentation on the BTS is quite lacking. Looking at the bottom of page, the last page is last modified on 31 Dec 2009, which isn't update for quite a while. Maybe we can have a wiki page on libreplanet like this one[0]. Anyone know how to add a new page on libreplanet wiki? (The earlier discussion regarding icecat and tor browser could also have its own page.) To close a bug, sending email to should work in theory, but I haven't try it yet. > I think this could really work out.. It would also establish some kind > of work flow, where currently we have one, but you are rather free in > how it all works out. > This would also help to avoid parallel work. Someone wanted to package > pybitmessage while I already had pybitmessage packaged, things like > that. > Please Feel free to discuss. Here is only my initial thought (heavily borrowed from debian): 1. File bug report to with the title being "PACKAGENAME@VERSION".(It can be changed later via bug control.) The content of the bug report should mention the license of the software. 2. Patch reviewing and responding are done by sending email to . 3. Bug report is closed when patch is pushed (we could even automate this one). Note that this does not account for patches which does not bump the version, maybe we should keep the bug report of version N opened and only close it when version N+1 is pushed. What do you and the others think? > Appending to my previous email, as John did not provide a link this is > the Aegis which was meant: http://aegis.sourceforge.net/ [0]: https://wiki.debian.org/HowtoUseBTS