emacs-devel
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]