From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: Feedback, ideas, discussion: tracking patches, discussions, bugs. Date: Sat, 3 Sep 2016 18:44:41 +0200 Message-ID: <20160903164441.GA1821@thebird.nl> References: <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> <878tvafu6g.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgE4S-0006G2-AU for guix-devel@gnu.org; Sat, 03 Sep 2016 12:45:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgE4O-0008FP-0a for guix-devel@gnu.org; Sat, 03 Sep 2016 12:45:32 -0400 Received: from mail.thebird.nl ([95.154.246.10]:52287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgE4N-0008Cv-OF for guix-devel@gnu.org; Sat, 03 Sep 2016 12:45:27 -0400 Content-Disposition: inline In-Reply-To: <878tvafu6g.fsf@gmail.com> 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: Alex Vong Cc: guix-devel@gnu.org, ng0 Today was pretty much an E-mail overload on the ML. In itself amazing :) Pj. On Fri, Sep 02, 2016 at 06:54:47PM +0800, Alex Vong wrote: > 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 > --