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: ng0
Subject: Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.
Date: Thu, 01 Sep 2016 11:19:00 +0000

ng0 <address@hidden> writes:

> it seems that gitlab can not be used because we require enterprise:
> https://lists.gnu.org/archive/html/guix-devel/2016-08/msg02152.html
>
> I keep searching and trying out systems, but it almost seems like to
> meet a consent where everyone gets what they want, it needs to be
> written. Of course it could be better if we would not have around 32
> regular contributors and only around 3 regular reviewers, but for people
> who approached me outside of the official channels Email is much more
> than just an annoyance, it's impossible for them to contribute due to
> various reasons.
>
> I remember using kallithea for a while, but I don't know how good or bad
> it was, which features it had. I need to setup an instance and see
> what's it like.
> It's sauce is here: https://kallithea-scm.org/repos/kallithea

I asked in their irc chat, and issues/bug tracking is (somewhere) on the
roadmap, but currently not being worked on.

My further 2cts:

- Mantis[0] has some nice features and is in general good to work, but I
  don't know about the administration, if it's easy to maintain.

- perl, debian (some of their projects), nasa, and lots of others are
  using RT (request tracker[1]). My only contact with it was at the perl
  side as a bug reporter. It provided me with a way to report bugs even
  without signing up, in the webbrowser.


Ultimately, it's not about the software but about reviewing. I want a
section "reviewing" in the manual, and in my opinion we should
encourage contributors to review and give them the right tools to do so.
My translation from the original IT/GER text to english takes a while,
but there's a nice article someone wrote about a certain topic which can
be applied here in our situation.
For the moment I think everyone who can should (but not must) review at
least 1 patch per month or even per week.
I think that's the best way to solve the situation right now, right
here with what we have. Take a patch, review it, one burden taken from
the backs of the usual ~3 suspects (reviewers).

The problem is the current tool for the distribution of the messages
(the framework of applications known as email). It does not include ways
to take the burden of management of your own backs. It does not help you
to sort, prioritize, filter, highlight, assign $person to $job etc, the
framework itself is minimal. You need to apply many hours of work and
search to get the right tool(s) for the jobs email doesn't do. I want
this burden gone for those who do not want it or can't deal with it
otherwise, lower the amount of information you are required to process
per month if you start contribution.

I begin to suspect that what I want has not been written, like in
several other cases I ran into in the last years.

[0] http://www.mantisbt.org , https://en.wikipedia.org/wiki/Mantis_Bug_Tracker
[1] https://bestpractical.com/request-tracker
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org



reply via email to

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