[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: contributing to Emacs
From: |
Konstantin Kharlamov |
Subject: |
Re: contributing to Emacs |
Date: |
Sun, 18 Jun 2023 13:44:59 +0300 |
User-agent: |
Evolution 3.48.2 |
On Sun, 2023-06-18 at 13:36 +0300, Eli Zaretskii wrote:
> > 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:27:47 +0300
> >
> > > 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.
> >
> > Well, you see, the "sending patches" section has no mention that a series is
> > unwelcome.
>
> They aren't "unwelcome", please don't misquote what I write.
Hmm, I feel like there's some confusion. You said that a single patch is
preferred over a series, right? And then you said it is the reason we don't need
to do anything about the problem with sending a series to bug-gnu-emacs@gnu.org
But the problem exists, so I'm suggesting that if you don't want it to be fixed,
perhaps we should put some docs about that.
If you say a series is not "unwelcome", then this documentation should simply
mention the problem.
> > If series is indeed unwelcome, it would be better to reflect in "sending
> > patches" section and provide copy-paste instructions for the people to
> > quickly
> > squash their commits before sending to ML (and I think something needs to be
> > figured out about commit messages too in this case). Because when you are
> > developing, it is easier to separate changes to distinct commits to make
> > sure
> > that if something break you know what exactly change was the reason to it.
> > Even
> > if these commits will have to be squashed later.
>
> It sounds like you have just asked us to make that section larger, is
> that right?
Yes, but it can still be easier to read than it is now. A few mails above I put
a suggestion to separate "how to send a patch" and "what changes should it
contain" to different chapters (ideally contained on a single page though). I
can rewrite the section and send it here if there's any interest. I didn't get
any reply if such change is welcome or not, but I imagine it would simplify the
page a lot.
- 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, 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 <=
- 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
- Re: contributing to Emacs, Dr. Arne Babenhauserheide, 2023/06/18
- Re: contributing to Emacs, Konstantin Kharlamov, 2023/06/18
- Re: contributing to Emacs, Po Lu, 2023/06/18