guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Vong
Subject: Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.
Date: Fri, 02 Sep 2016 18:54:47 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]