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. 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. Appending to my previous email, as John did not provide a link this is the Aegis which was meant: http://aegis.sourceforge.net/ -- ng0 For non-prism friendly talk find me on http://www.psyced.org