diff mbox series

[1/1] docs: update DEVELOPERS modification process

Message ID 20171103211053.20886-1-joseph.kogut@gmail.com
State Accepted
Commit 8209d72211ab9b8f84ad89aa62f2b038211c32bb
Headers show
Series [1/1] docs: update DEVELOPERS modification process | expand

Commit Message

Joseph Kogut Nov. 3, 2017, 9:10 p.m. UTC
Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 docs/manual/contribute.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--
2.15.0

Comments

Baruch Siach Nov. 4, 2017, 6:53 p.m. UTC | #1
Hi Joseph,

On Fri, Nov 03, 2017 at 02:10:53PM -0700, Joseph Kogut wrote:
> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> ---
>  docs/manual/contribute.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> 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.

baruch
Thomas Petazzoni Nov. 4, 2017, 10:14 p.m. UTC | #2
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
Baruch Siach Nov. 5, 2017, 6:07 a.m. UTC | #3
Hi Thomas,

On Sat, Nov 04, 2017 at 11:14:27PM +0100, Thomas Petazzoni wrote:
> 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.

Ah. For some reason I had the impression that this change is against the 
DEVELOPERS file itself. So let me rephrase my suggestion:

  I suggest to drop this sentence entirely, and leave the details for the 
  DEVELOPERS manual section.

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

Agreed.

baruch
Peter Korsgaard Nov. 5, 2017, 7:43 a.m. UTC | #4
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

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

I'm not sure it really matters much. A package change with a
modification of DEVELOPERS would most likely be for a version bump of an
unmaintained package where the person bumping wants to take over
ownership, or similar.

I don't think it is a problem to update DEVELOPERS together with the
package in such cases, but keeping it separately is also fine.
Thomas Petazzoni Nov. 5, 2017, 8:55 a.m. UTC | #5
Hello,

On Sun, 5 Nov 2017 08:07:49 +0200, Baruch Siach wrote:

> > > 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.  
> 
> Ah. For some reason I had the impression that this change is against the 
> DEVELOPERS file itself. So let me rephrase my suggestion:
> 
>   I suggest to drop this sentence entirely, and leave the details for the 
>   DEVELOPERS manual section.

No, I think it is good to have this sentence in the "Adding a new
package" section of the manual. Indeed new contributors are much more
likely to read this section when contributing a new package than an
obscure section specific to the DEVELOPERS file at the end of the
manual.

Best regards,

Thomas
Thomas Petazzoni Nov. 5, 2017, 8:55 a.m. UTC | #6
Hello,

On Sun, 05 Nov 2017 08:43:05 +0100, Peter Korsgaard wrote:

>  > 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.  
> 
> I'm not sure it really matters much. A package change with a
> modification of DEVELOPERS would most likely be for a version bump of an
> unmaintained package where the person bumping wants to take over
> ownership, or similar.
> 
> I don't think it is a problem to update DEVELOPERS together with the
> package in such cases, but keeping it separately is also fine.

Agreed.

Thomas
Peter Korsgaard Nov. 5, 2017, 8:14 p.m. UTC | #7
>>>>> "Joseph" == Joseph Kogut <joseph.kogut@gmail.com> writes:

 > Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
 > ---
 >  docs/manual/contribute.txt | 6 +++---
 >  1 file changed, 3 insertions(+), 3 deletions(-)

Committed, thanks.
diff mbox series

Patch

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.

 ==== Preparing a patch series