Re: [REQ/DISCUSSION] patch managing system

[Nils Gillmann <niasterisk@grrlz.net>]

Nils Gillmann <niasterisk@grrlz.net> writes:

> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>
>> Nils Gillmann <niasterisk@grrlz.net> 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.

Appended: maybe not, just went through emacs-devel and it seems
to be working out with discussion and patches.
Only -help at our side, there are some threads in -devel which
would be more suited for -help.

> (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