Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Pjotr Prins]

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 <address@hidden> writes:
> 
> > Alex Vong <address@hidden> 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 <address@hidden>. 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 <address@hidden>
> 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 <address@hidden> with the title
>   being "address@hidden".(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
>   <address@hidden>.
>   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
> 

--