docs: update DEVELOPERS modification process
PATCH 1/1 docs: update DEVELOPERS modification process
--- docs/manual/contribute.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
docs/manual/contribute.txt +3 -3
@@ -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
--
2.15.0
PATCH 1/1 docs: update DEVELOPERS modification process
Hi Joseph,
Quoted 10 lines · Joseph Kogut
Signed-off-by Joseph Kogut <[email protected]>--- docs/manual/contribute.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)docs/manual/contribute.txt +0
-0
docs/manual/contribute.txt options that no longer exist or are no longer needed. · line 265
Quoted 9 lines
docs/manual/contribute.txt +3
-3@@ -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
Signature · 3 lines
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -PATCH 1/1 docs: update DEVELOPERS modification process
Hello,
Quoted 6 lines · Baruch Siach
Quoted 6 lines
docs/manual/contribute.txt +0
-0@@ -260,9 +260,9 @@ options that no longer exist or are no longer needed.
Quoted 13 lines
docs/manual/contribute.txt options that no longer exist or are no longer needed. · line 265
Quoted 8 lines
docs/manual/contribute.txt +3
-3If 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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 docs: update DEVELOPERS modification process
Hi Thomas,
Quoted 22 lines · Thomas Petazzoni
Quoted 6 lines · Baruch Siach
Quoted 6 lines
docs/manual/contribute.txt +0
-0@@ -260,9 +260,9 @@ options that no longer exist or are no longer needed.Quoted 13 lines
docs/manual/contribute.txt options that no longer exist or are no longer needed. · line 265
Quoted 8 lines
docs/manual/contribute.txt +3
-3If 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.
Quoted 2 lines
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.
Quoted 6 lines
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
Signature · 3 lines
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -PATCH 1/1 docs: update DEVELOPERS modification process
Hello,
Quoted 5 lines · Baruch Siach
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 2 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 docs: update DEVELOPERS modification process
In reply to Thomas PetazzoniQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 8 lines
Quoted 4 lines
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.
Quoted 6 lines
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.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 docs: update DEVELOPERS modification process
Hello,
Quoted 7 lines · Peter Korsgaard
Quoted 6 lines
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.
Quoted 7 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 docs: update DEVELOPERS modification process
In reply to Joseph KogutQuoted 6 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Joseph" == Joseph Kogut <[email protected]> writes:
Signed-off-by Joseph Kogut <[email protected]>--- docs/manual/contribute.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard