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

[ng0]

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.

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