[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: contributing to Emacs
From: |
Eli Zaretskii |
Subject: |
Re: contributing to Emacs |
Date: |
Sun, 18 Jun 2023 13:22:51 +0300 |
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 13:13:23 +0300
>
> On Sun, 2023-06-18 at 13:02 +0300, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org, luangruo@yahoo.com,
> > > emacs-devel@gnu.org
> > > Date: Sun, 18 Jun 2023 12:56:33 +0300
> > >
> > > Okay, so, here's an obvious one: a patch series sent to
> > > bug-gnu-emacs@gnu.org
> > > should not create separate bugreports for every patch.
> > >
> > > In ML-managed projects it is typical to send patches as a series, and when
> > > you
> > > doing that results in such surprising behaviour, it creates an additional
> > > emotional and mental load both for you and for maintainers who would need
> > > to
> > > do
> > > something with these separate reports.
> >
> > Our preference is to send patches as a single patch, not as patch
> > series.
> >
> > That said, people are sometimes sending series, and we don't ask them
> > to resend, we process those series anyway.
> >
> > As for separate bug reports, this is easily fixed by merging them.
>
> Unfortunately merging bugreports does not fix that. The last patch I had to
> Emacs was sent with a cover letter and resulted in two reports: one for the
> cover letter and another for the patch itself. You may remember that it
> resulted
> in a confusion, because α) discussions happened on both threads, but then a
> new
> patch version was only sent to one of them, so there other thread wasn't
> notified that comments were addressed, and β) you may remember 3 months after
> the patch got accepted someone was asking the status. Which is because one of
> the threads was closed saying that the patch is applied, but then the other
> thread into which a person was looking has no such comment.
>
> > So I see no problem here.
>
> This is psychology. Having a report per patch may not be a problem for you,
> but
> when a contributor sends patches and gets into such situation, they do not
> know
> it is okay. They will be frightened and frustrated, because it looks like
> something just went wrong. Such situation being okay needs at least be
> mentioned
> in "sending patches" section, and at best it should just work.
Like I said: we prefer a single patch for each changeset. The
problems presented by patch series are one reason. And yet, we will
never reject a patch series, even though it makes the process
inconvenient and confusing.
I don't see what else do we need to argued about here.
- Re: contributing to Emacs, (continued)
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Dr. Arne Babenhauserheide, 2023/06/18
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Eli Zaretskii, 2023/06/18
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs,
Eli Zaretskii <=
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Eli Zaretskii, 2023/06/18
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Eli Zaretskii, 2023/06/18
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Eli Zaretskii, 2023/06/18
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Eli Zaretskii, 2023/06/18
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Dr. Arne Babenhauserheide, 2023/06/18