Re: [REQ/DISCUSSION] patch managing system

[Nils Gillmann]

Ricardo Wurmus <address@hidden> writes:

> Nils Gillmann <address@hidden> writes:
>
>> First follow up idea:
>>
>> Ideal case would be:
>>  - integration with Guix in the future (the emacs interface and
>>    other potential future interfaces)
>>  - integration into Guix website
>>  - patches can be marked:
>>    - state (done/open)
>>    - priority
>>  - patches can be assigned to more than 1 person
>>  - webinterface
>>
>> As we are not at the ideal case and need a software until we get
>> there, most projects seem to either use mailman, bugzilla,
>> something equal to prmon.freebsd.org (ports monitor), simple pull
>> requests on a mirror on a bigger source control system.
>
> I have a very strong aversion to bugzilla and other complicated tracking
> systems.  All of the above points are covered by debbugs, which we
> already use for bug tracking.

That's right, rain1 pointed this out to me in irc some moments ago.

> debbugs has an Emacs interface as well as a read-only web interface.
>
> I must admit that I’m not using debbugs regularly for our bug tracker
> because I’m not working on bugs very often.  If we really wanted to
> track progress on patches we could be using debbugs, but I don’t
> actually think it would improve the situation much.
>
> Right now I’m capturing guix-devel emails that I want to look at later
> with Org capture, or I simply leave them in an unread state.  The
> problem, in my opinion, is not so much keeping track of patches, but
> taking the time to review and engage in discussions.  I cannot review as
> much as I would like to and for follow up discussions I often miss time
> (in front of the computer, and in a reasonably awake state).

Would it make sense to have a patches-only list or at least a
separation between [general not-patch-related disussions,
questions, pre-bug report questions] and [patches and their
discussions]?
This would not fix the people and times situation
but eventually prevent situations in the future where we only
have -devel for discussions, questions, patches, pre-bug
questions, and with a growing number of participants more
reviewers might come, but also more questions and other non-patch
related input on the list, making it /maybe/ difficult to
follow.
I think it's better to think ahead and solve problems
before they become problems, but maybe this is too soon.

(sidenote:
I envision something for much later which I will discuss in
another project and see if it fits into what we (in that project)
focus on, maybe in a couple of years it could be useful.)

> I don’t think it’s a software problem, but a people problem.  To deal
> with more patches we need more people reviewing patches.  We already
> have “guix lint” to point out common problems.  We probably should add a
> little helper script for all non-Emacsers that runs Emacs over the
> expression to check the indentation.  But other than that I’d just say:
>
> resend a patch if you haven’t received any response within five days or
> so.

>From my perspective, resending does not really help either. It
fills up the mailinglist with duplicates and unless I mention
which of these threads can be considered closed, any version
could be seen as the patch and it only works around the problem
you mentioned and I see - too little people to review and apply
patches.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN