A bug tracker (was: Re: [Bug] Unexpected process suspension)

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Rudi C wrote on Thu, 21 May 2020 03:02 +0430:
> Considering this bug (or a very similar variant) was reported before and
> the issue just died a silent death, I think it's a good idea to create a
> Github repo for tracking zsh issues. Github issue tracker is a lot better
> than mailing lists, as things have a dichotomy of being  open/closed, and
> can be labeled. It is harder for issues to die a silent death there.

I'm not opposed to adding a proper issue tracker, but github is not the
only fish in the sea; it is one option among many.

IIRC, last time this was discussed, it was requested to have
bidirectional integration with the mailing list.  Do I recall correctly?

If we opt for an issue tracker, there'll be the question of whether
we'll use the issue tracker to receive/triage bug reports, or keep
triage on the mailing lists like today and only use the tracker to
record known defects and conclusions of discussions.  The latter would
be the smaller change compared to the status quo.

Another way to solve this is to have a "bug reports manager", who would
be a volunteer who'd scan the lists regularly — say, once a week — for
any bug report threads that have petered out without a solution, and
ping those.  (The volunteer needn't be a developer.)  I filled a similar
role myself, years ago at $OTHERPROJECT.  Compare
https://producingoss.com/en/share-management.html#manager-is-not-owner
(particularly its first subsection, read with s/patch/bug report/g).

Finally, I have been using Etc/BUGS in git to track bugs.  If someone'd
like to add an entry there for this set of related bugs, please do.

> It is also easier to contribute to that, and easier to unsubscribe
> (I don't think one can unsubscribe from a mailing list post one
> participated in, as people (wisely) use reply-all.).

No, it's not possible to unsubscribe from being directly Cc'd, but the
responses generally peter out after a few days, and there are plenty of
ways to deduplicate or otherwise flag responses that were Cc'd both to
oneself and to the list.

Cheers,

Daniel

> On Wed, May 13, 2020 at 10:59 AM Stephane Chazelas <stephane@xxxxxxxxxxxx>
> wrote:
> 
> > 2020-05-12 10:38:38 -0700, Bart Schaefer:  
> > > On Tue, May 12, 2020 at 12:03 AM Rudi C <rudiwillalwaysloveyou@xxxxxxxxx>  
> > wrote:  
> > > >
> > > > mdoc-test () {
> > > >
> > > >     sleep 0 | sleep 0  
> > > >     cat}  
> > > >
> > > > echo start |VISUAL=vim command vipe|mdoc-test
> > > >
> > > > # zsh: suspended (tty output)  
> > >
> > > Putting an interactive command in the middle of a pipeline is
> > > generally not going to work.  Vim in particular is pretty aggressive
> > > about trying to grab a terminal, which will result in processes
> > > getting SIGTT* because they don't have foreground control of the
> > > terminal they're trying to use.  
> > [...]
> >
> > The thing is vim *should* be in the foreground, all the
> > processes started in pipeline should be in the same process
> > group which should be in foreground (so it gets
> > SIGINT/SIGQUIT/SIGTSTP upon ^C/^\/^Z, so it can read the
> > terminal, etc) but under some circumstances, zsh fails to put
> > some processes in that group, which is a bug.
> >
> > $ </proc/self/stat awk '{print $5, $8}' >&2
> > 127235 127235
> > $ </proc/self/stat awk '{print $5, $8; system("exec sleep 1")}'  >&2 | ps
> > -o pid,pgid,comm
> > 131569 131569
> >     PID    PGID COMMAND
> >  124948  124948 zsh
> >  131569  131569 awk
> >  131570  131569 ps
> >  131571  131569 sleep
> > $ </proc/self/stat awk '{print $5, $8}' >&2 | { :; }
> > 127410 127410
> > $ </proc/self/stat awk '{print $5, $8}' >&2 | { : | :; }
> > 127496 124948
> >
> > In that latter case, awk is in a different process group
> > (127496) from the terminal foreground process group (124948
> > which here is the process group of the main shell process!).
> >
> > --
> > Stephane
> >