All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] docs: update DEVELOPERS modification process
Date: Sat, 4 Nov 2017 23:14:27 +0100	[thread overview]
Message-ID: <20171104231427.3b3f436a@windsurf> (raw)
In-Reply-To: <20171104185305.5vkjjg6iwrhctcis@tarshish>

Hello,

On Sat, 4 Nov 2017 20:53:05 +0200, Baruch Siach wrote:

> > diff --git a/docs/manual/contribute.txt b/docs/manual/contribute.txt
> > index a58945f395..8bbc2b9eb7 100644
> > --- a/docs/manual/contribute.txt
> > +++ b/docs/manual/contribute.txt
> > @@ -260,9 +260,9 @@ options that no longer exist or are no longer needed.
> > 
> >  If you are interested in getting notified of build failures and of
> >  further changes in the packages you added or modified, please add
> > -yourself to the DEVELOPERS file. This should be done in a separate
> > -patch of the series. See xref:DEVELOPERS[the DEVELOPERS file] for more
> > -information.
> > +yourself to the DEVELOPERS file. This should be done in the same patch
> > +creating or modifying the package. See xref:DEVELOPERS[the DEVELOPERS file]
> > +for more information.  
> 
> Not sure about "or modifying". Mixing a DEVELOPERS update into a random 
> package update does not always make sense. The manual only refers to new 
> packages/boards. I suggest to drop this sentence entirely, and leave the 
> details for the manual.

Joseph is modifying the manual here, so I'm not sure what your last
sentence means.

However, I agree that doing the DEVELOPERS change in a patch just
modifying the package is perhaps not desirable. When adding a new
package, yes, definitely, the DEVELOPERS entry should be added as part
of the same patch. However, when a package is being modified, that's a
different story, and the package change should be in a separate patch
than the DEVELOPERS addition.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2017-11-04 22:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-03 21:10 [Buildroot] [PATCH 1/1] docs: update DEVELOPERS modification process Joseph Kogut
2017-11-04 18:53 ` Baruch Siach
2017-11-04 22:14   ` Thomas Petazzoni [this message]
2017-11-05  6:07     ` Baruch Siach
2017-11-05  8:55       ` Thomas Petazzoni
2017-11-05  7:43     ` Peter Korsgaard
2017-11-05  8:55       ` Thomas Petazzoni
2017-11-05 20:14 ` Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171104231427.3b3f436a@windsurf \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.