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 <n...@n0.is> writes: > > > Alex Vong <alexvong1...@gmail.com> 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 <bug-guix-pack...@gnu.org>. 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 <bugnumber-d...@debbugs.gnu.org> > 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 <bug-guix-pack...@debbugs.org> 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 > <bugnum...@debbugs.gnu.org>. > 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 > --
