Questions about the contributing process

Questions about the contributing process

[Matheus Tavares Bernardino]

Hello everyone

It's been a few months since I started sending patches, but there are
still some points about the process that I do not quite understand. I
would be really grateful if anyone could help clarify them for me.

1) How do we credit more than one person as an author? Here at the
University of S=C3=A3o Paulo we sometimes develop patches in pair
programming, and I don't really know if in these cases we should just
add the S-o-B of both authors or add the "Co-Developed-by" tag (or
something else). Also, is this something specific to each subsystem?

2) Does iio have a test infrastructure? I know there are autobuilders
playing with the iio.git testing branch, but how does it work? Also,
if there is no test beyond building, is there some plan to make such
an infrastructure in the near future?

3) When a reviewer sends an Acked-by, but I still have to send a v2
for some reason (maybe adjusting the patch message, e.g.), should I
add the Acked-by in v2 or that's something the maintainers will do?

Thank you
Matheus

Questions about the contributing process

[Matheus Tavares Bernardino]

Hello everyone

It's been a few months since I started sending patches, but there are
still some points about the process that I do not quite understand. I
would be really grateful if anyone could help clarify them for me.

1) How do we credit more than one person as an author? Here at the
University of São Paulo we sometimes develop patches in pair
programming, and I don't really know if in these cases we should just
add the S-o-B of both authors or add the "Co-Developed-by" tag (or
something else). Also, is this something specific to each subsystem?

2) Does iio have a test infrastructure? I know there are autobuilders
playing with the iio.git testing branch, but how does it work? Also,
if there is no test beyond building, is there some plan to make such
an infrastructure in the near future?

3) When a reviewer sends an Acked-by, but I still have to send a v2
for some reason (maybe adjusting the patch message, e.g.), should I
add the Acked-by in v2 or that's something the maintainers will do?

Thank you
Matheus

Re: Questions about the contributing process

[Jonathan Cameron]

On Sat, 1 Dec 2018 14:51:07 -0200
Matheus Tavares Bernardino <matheus.bernardino@usp.br> wrote:

> Hello everyone
Hi Matheus.
> 
> It's been a few months since I started sending patches, but there are
> still some points about the process that I do not quite understand. I
> would be really grateful if anyone could help clarify them for me.
> 
> 1) How do we credit more than one person as an author? Here at the
> University of São Paulo we sometimes develop patches in pair
> programming, and I don't really know if in these cases we should just
> add the S-o-B of both authors or add the "Co-Developed-by" tag (or
> something else). Also, is this something specific to each subsystem?

It's certainly an interesting one and an area we probably need to
have a solution for in general given that methodologies such
as pair programming are becoming more common.

For IIO I have no real problem with multiple sign offs though slight
preference for having that and Co-Developed-by to explain the
additional signed-off-by is part of the actual developer's
Developer Certificate of Origin rather than one indicating having
'handled the patch' line mine is...

I've not often come across this one but see it's in submitting-patches.rst
and is nice and clear so I'll be pushing for people to do this in future! 

> 
> 2) Does iio have a test infrastructure? I know there are autobuilders
> playing with the iio.git testing branch, but how does it work? Also,
> if there is no test beyond building, is there some plan to make such
> an infrastructure in the near future?

This is indeed an area we are very weak on.  Partly this is about the
difficulty of having any sort of centralised test facility given the
huge number of devices that would be needed.  Hence it comes down
to individual developers testing patches that touch their drivers.
I assume that some of the larger companies have automated test setups
but don't actually know that.

I've thought about building a small CI setup myself but never actually
had the time to get it all wired up.  A certain class of device would
be fairly easy, though it would still require proper wiring rather than
the bunch of probes I often end up with whilst testing!
Others such as motion sensors would require another
level of automation to do any sort of thorough testing.

Hence all we have running all the time is the 0day build bots that
Intel kindly provide for the community.  Those will do a lot of build
and boot testing but there is no IIO specific testing in there. Kernelci
and other boot test focused systems will hit the code once it reaches linux-next
which is after Greg pulls it (a couple of times a cycle).

Any progress in this area would be great. One day my garage may finally
gain a permanent test rig, but it's not at the top of my list for holiday
projects.

I know from the day job CI system, the huge amount of work in getting a
system set up and the constant maintenance burden that comes with it.
The effort of kernelci has certainly made the tooling easier to get
and use, but it is the perpetual issue with flakey hardware that keeps
things busy once you reach a certain scale of testing.  Have 10+ boards
and one of them will almost always be broken either physically or
in software terms.  For some classes of sensor we could standardise
on a host which would reduce the chance of this. The SoC ADCs won't
work for this though.

> 
> 3) When a reviewer sends an Acked-by, but I still have to send a v2
> for some reason (maybe adjusting the patch message, e.g.), should I
> add the Acked-by in v2 or that's something the maintainers will do?

If there are no substantial changes to the actual code, or they are ones
the person giving the tags requested, please add any tags to your V2.
I will occasionally remember to go back through old series because I know
someone gave a tag, but mostly I will only look at the latest version when
applying and assume all tags will already be there.

If you know I have missed one on a particular series, please point it
out as I may well not have pushed out a non rebasing version of the tree
(the main togreg branch) yet and so can edit the history to add the tag.
I often do this for DT reviews when I've assumed the patch was so simple
Rob wouldn't comment, neglecting how thorough he sometimes is and the
review comes in post me applying it!

> 
> Thank you
> Matheus

All good thought provoking questions (particularly the testing one!).
Keep them coming as it's useful stuff for everyone to know.

There is the new Subsystem maintainer doc that I need to sit down and
write for IIO. https://lwn.net/Articles/772882/ (pay walled currently)

https://lwn.net/ml/linux-kernel/154225759358.2499188.15268218778137905050.stgit@dwillia2-desk3.amr.corp.intel.com/#t

I'll try and remember to put the answers to these in there.
Note it'll probably be the Xmas week before I sit down and write that though.

Jonathan

Re: Questions about the contributing process

[Matheus Tavares Bernardino]

Thanks a lot for the great answers, Jonathan!
Some comments about them, inline.

On Sat, Dec 1, 2018 at 4:08 PM Jonathan Cameron
<jic23@jic23.retrosnub.co.uk> wrote:
>
> On Sat, 1 Dec 2018 14:51:07 -0200
> Matheus Tavares Bernardino <matheus.bernardino@usp.br> wrote:
>
> > Hello everyone
> Hi Matheus.
> >
> > It's been a few months since I started sending patches, but there are
> > still some points about the process that I do not quite understand. I
> > would be really grateful if anyone could help clarify them for me.
> >
> > 1) How do we credit more than one person as an author? Here at the
> > University of São Paulo we sometimes develop patches in pair
> > programming, and I don't really know if in these cases we should just
> > add the S-o-B of both authors or add the "Co-Developed-by" tag (or
> > something else). Also, is this something specific to each subsystem?
>
> It's certainly an interesting one and an area we probably need to
> have a solution for in general given that methodologies such
> as pair programming are becoming more common.
>
> For IIO I have no real problem with multiple sign offs though slight
> preference for having that and Co-Developed-by to explain the
> additional signed-off-by is part of the actual developer's
> Developer Certificate of Origin rather than one indicating having
> 'handled the patch' line mine is...
>
> I've not often come across this one but see it's in submitting-patches.rst
> and is nice and clear so I'll be pushing for people to do this in future!
>

Great! I'm going to forward this to my USP colleagues so we can start
using Co-Developed-by, in addition to S-o-B.

> >
> > 2) Does iio have a test infrastructure? I know there are autobuilders
> > playing with the iio.git testing branch, but how does it work? Also,
> > if there is no test beyond building, is there some plan to make such
> > an infrastructure in the near future?
>
> This is indeed an area we are very weak on.  Partly this is about the
> difficulty of having any sort of centralised test facility given the
> huge number of devices that would be needed.  Hence it comes down
> to individual developers testing patches that touch their drivers.
> I assume that some of the larger companies have automated test setups
> but don't actually know that.
>
> I've thought about building a small CI setup myself but never actually
> had the time to get it all wired up.  A certain class of device would
> be fairly easy, though it would still require proper wiring rather than
> the bunch of probes I often end up with whilst testing!
> Others such as motion sensors would require another
> level of automation to do any sort of thorough testing.
>

It does really seems to be a hard job to build and maintain a CI setup
for so many devices. But couldn't we have at least a simpler test
suite, made entirely in software, that mocks [some off] the devices
and tests part of the subsystem code? I know it wouldn't be as good as
having all the physical hardware and wiring to test, but maybe it
could be a start.

In addition it would facilitate the process of contribution and
revision because the test software could be run locally and would
encounter problems in the patches before they were sent.

> Hence all we have running all the time is the 0day build bots that
> Intel kindly provide for the community.  Those will do a lot of build
> and boot testing but there is no IIO specific testing in there. Kernelci
> and other boot test focused systems will hit the code once it reaches linux-next
> which is after Greg pulls it (a couple of times a cycle).
>
> Any progress in this area would be great. One day my garage may finally
> gain a permanent test rig, but it's not at the top of my list for holiday
> projects.
>
> I know from the day job CI system, the huge amount of work in getting a
> system set up and the constant maintenance burden that comes with it.
> The effort of kernelci has certainly made the tooling easier to get
> and use, but it is the perpetual issue with flakey hardware that keeps
> things busy once you reach a certain scale of testing.  Have 10+ boards
> and one of them will almost always be broken either physically or
> in software terms.  For some classes of sensor we could standardise
> on a host which would reduce the chance of this. The SoC ADCs won't
> work for this though.
>
> >
> > 3) When a reviewer sends an Acked-by, but I still have to send a v2
> > for some reason (maybe adjusting the patch message, e.g.), should I
> > add the Acked-by in v2 or that's something the maintainers will do?
>
> If there are no substantial changes to the actual code, or they are ones
> the person giving the tags requested, please add any tags to your V2.
> I will occasionally remember to go back through old series because I know
> someone gave a tag, but mostly I will only look at the latest version when
> applying and assume all tags will already be there.
>

Ok, got it. Thanks.

> If you know I have missed one on a particular series, please point it
> out as I may well not have pushed out a non rebasing version of the tree
> (the main togreg branch) yet and so can edit the history to add the tag.
> I often do this for DT reviews when I've assumed the patch was so simple
> Rob wouldn't comment, neglecting how thorough he sometimes is and the
> review comes in post me applying it!
>
> >
> > Thank you
> > Matheus
>
> All good thought provoking questions (particularly the testing one!).
> Keep them coming as it's useful stuff for everyone to know.
>
> There is the new Subsystem maintainer doc that I need to sit down and
> write for IIO. https://lwn.net/Articles/772882/ (pay walled currently)
>
> https://lwn.net/ml/linux-kernel/154225759358.2499188.15268218778137905050.stgit@dwillia2-desk3.amr.corp.intel.com/#t
>
> I'll try and remember to put the answers to these in there.
> Note it'll probably be the Xmas week before I sit down and write that though.
>

Great! Thanks again for all the explanations.

Matheus

Re: Questions about the contributing process

[Jonathan Cameron]

On Sat, 1 Dec 2018 17:05:33 -0200
Matheus Tavares Bernardino <matheus.bernardino@usp.br> wrote:

> Thanks a lot for the great answers, Jonathan!
> Some comments about them, inline.
> 
> On Sat, Dec 1, 2018 at 4:08 PM Jonathan Cameron
> <jic23@jic23.retrosnub.co.uk> wrote:
> >
> > On Sat, 1 Dec 2018 14:51:07 -0200
> > Matheus Tavares Bernardino <matheus.bernardino@usp.br> wrote:
> >  
> > > Hello everyone  
> > Hi Matheus.  
> > >
> > > It's been a few months since I started sending patches, but there are
> > > still some points about the process that I do not quite understand. I
> > > would be really grateful if anyone could help clarify them for me.
> > >
> > > 1) How do we credit more than one person as an author? Here at the
> > > University of São Paulo we sometimes develop patches in pair
> > > programming, and I don't really know if in these cases we should just
> > > add the S-o-B of both authors or add the "Co-Developed-by" tag (or
> > > something else). Also, is this something specific to each subsystem?  
> >
> > It's certainly an interesting one and an area we probably need to
> > have a solution for in general given that methodologies such
> > as pair programming are becoming more common.
> >
> > For IIO I have no real problem with multiple sign offs though slight
> > preference for having that and Co-Developed-by to explain the
> > additional signed-off-by is part of the actual developer's
> > Developer Certificate of Origin rather than one indicating having
> > 'handled the patch' line mine is...
> >
> > I've not often come across this one but see it's in submitting-patches.rst
> > and is nice and clear so I'll be pushing for people to do this in future!
> >  
> 
> Great! I'm going to forward this to my USP colleagues so we can start
> using Co-Developed-by, in addition to S-o-B.
> 
> > >
> > > 2) Does iio have a test infrastructure? I know there are autobuilders
> > > playing with the iio.git testing branch, but how does it work? Also,
> > > if there is no test beyond building, is there some plan to make such
> > > an infrastructure in the near future?  
> >
> > This is indeed an area we are very weak on.  Partly this is about the
> > difficulty of having any sort of centralised test facility given the
> > huge number of devices that would be needed.  Hence it comes down
> > to individual developers testing patches that touch their drivers.
> > I assume that some of the larger companies have automated test setups
> > but don't actually know that.
> >
> > I've thought about building a small CI setup myself but never actually
> > had the time to get it all wired up.  A certain class of device would
> > be fairly easy, though it would still require proper wiring rather than
> > the bunch of probes I often end up with whilst testing!
> > Others such as motion sensors would require another
> > level of automation to do any sort of thorough testing.
> >  
> 
> It does really seems to be a hard job to build and maintain a CI setup
> for so many devices. But couldn't we have at least a simpler test
> suite, made entirely in software, that mocks [some off] the devices
> and tests part of the subsystem code? I know it wouldn't be as good as
> having all the physical hardware and wiring to test, but maybe it
> could be a start.

We definitely could.  Various options on this.  One is qemu, the
other is to just target i2c devices.  Guenter wrote some really
nice testing stuff for hwmon drivers using the emulated i2c slave.
https://github.com/groeck/module-tests

It's limited, but might go someway towards sanity checking some types
of change.

> 
> In addition it would facilitate the process of contribution and
> revision because the test software could be run locally and would
> encounter problems in the patches before they were sent.

This only works if the change is to the core, or to the particular
drivers we have emulation for.  We could potentially ask for
people to also submit emulation support,  but that is a significant
additional burden on the people who actually have the hardware and
hence are the least in need of emulation.

CI and test suites are lovely when you have some level of standardization
or simple ability to emulate, so they work great for things like filesystems
or where you only support a few platforms.  There have been various discussions
on whether the community will come together to build larger test farms
for hardware (way beyond what kernelci does currently) driven by the media
subsystem (who often lead on efforts like this).   I haven't heard about
any outcomes of that effort yet though.

Jonathan
> 
> > Hence all we have running all the time is the 0day build bots that
> > Intel kindly provide for the community.  Those will do a lot of build
> > and boot testing but there is no IIO specific testing in there. Kernelci
> > and other boot test focused systems will hit the code once it reaches linux-next
> > which is after Greg pulls it (a couple of times a cycle).
> >
> > Any progress in this area would be great. One day my garage may finally
> > gain a permanent test rig, but it's not at the top of my list for holiday
> > projects.
> >
> > I know from the day job CI system, the huge amount of work in getting a
> > system set up and the constant maintenance burden that comes with it.
> > The effort of kernelci has certainly made the tooling easier to get
> > and use, but it is the perpetual issue with flakey hardware that keeps
> > things busy once you reach a certain scale of testing.  Have 10+ boards
> > and one of them will almost always be broken either physically or
> > in software terms.  For some classes of sensor we could standardise
> > on a host which would reduce the chance of this. The SoC ADCs won't
> > work for this though.
> >  
> > >
> > > 3) When a reviewer sends an Acked-by, but I still have to send a v2
> > > for some reason (maybe adjusting the patch message, e.g.), should I
> > > add the Acked-by in v2 or that's something the maintainers will do?  
> >
> > If there are no substantial changes to the actual code, or they are ones
> > the person giving the tags requested, please add any tags to your V2.
> > I will occasionally remember to go back through old series because I know
> > someone gave a tag, but mostly I will only look at the latest version when
> > applying and assume all tags will already be there.
> >  
> 
> Ok, got it. Thanks.
> 
> > If you know I have missed one on a particular series, please point it
> > out as I may well not have pushed out a non rebasing version of the tree
> > (the main togreg branch) yet and so can edit the history to add the tag.
> > I often do this for DT reviews when I've assumed the patch was so simple
> > Rob wouldn't comment, neglecting how thorough he sometimes is and the
> > review comes in post me applying it!
> >  
> > >
> > > Thank you
> > > Matheus  
> >
> > All good thought provoking questions (particularly the testing one!).
> > Keep them coming as it's useful stuff for everyone to know.
> >
> > There is the new Subsystem maintainer doc that I need to sit down and
> > write for IIO. https://lwn.net/Articles/772882/ (pay walled currently)
> >
> > https://lwn.net/ml/linux-kernel/154225759358.2499188.15268218778137905050.stgit@dwillia2-desk3.amr.corp.intel.com/#t
> >
> > I'll try and remember to put the answers to these in there.
> > Note it'll probably be the Xmas week before I sit down and write that though.
> >  
> 
> Great! Thanks again for all the explanations.
> 
> Matheus

Re: Questions about the contributing process

[Himanshu Jha]

On Sat, Dec 01, 2018 at 02:51:07PM -0200, Matheus Tavares Bernardino wrote:
> Hello everyone
> 
> 2) Does iio have a test infrastructure? I know there are autobuilders
> playing with the iio.git testing branch, but how does it work?

https://01.org/lkp/documentation/0-day-test-service
https://github.com/fengguang/lkp-tests

> Also, if there is no test beyond building

+ booting
https://lists.01.org/pipermail/lkp/2018-December/009493.html
+ coccinelle
+ sparse
+ smatch
+ automatically sending fixes based on reports produced by 
  debugging tools
https://lore.kernel.org/lkml/20181127232130.GA28456@sof-kbuild01/

Earlier they used to also give performance + power tests too.

The build farm maintains around ~800 repos:
https://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git/tree/repo/linux?id=91bb38c4ee4e95e57f1647446dc20d66cc53f92e

You can find `iio` in above list.

Build testing in around ~150 or more kernel configs in ~1-2 hours
And sending the report immediately to the author by bisecting the
commit on the first failure.

I don't work for Intel but I have experienced the power of the
beast ;)

Anyway, for other queries on the development process, I think Rodrigo
Siqueira can help you too with a quick feedback belonging to the
same university.


Thanks!
-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

Re: Questions about the contributing process

[Matheus Tavares Bernardino]

On Sun, Dec 2, 2018 at 5:56 PM Himanshu Jha <himanshujha199640@gmail.com> wrote:
>
> On Sat, Dec 01, 2018 at 02:51:07PM -0200, Matheus Tavares Bernardino wrote:
> > Hello everyone
> >
> > 2) Does iio have a test infrastructure? I know there are autobuilders
> > playing with the iio.git testing branch, but how does it work?
>
> https://01.org/lkp/documentation/0-day-test-service
> https://github.com/fengguang/lkp-tests
>
> > Also, if there is no test beyond building
>
> + booting
> https://lists.01.org/pipermail/lkp/2018-December/009493.html
> + coccinelle
> + sparse
> + smatch
> + automatically sending fixes based on reports produced by
>   debugging tools
> https://lore.kernel.org/lkml/20181127232130.GA28456@sof-kbuild01/
>
> Earlier they used to also give performance + power tests too.
>
> The build farm maintains around ~800 repos:
> https://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git/tree/repo/linux?id=91bb38c4ee4e95e57f1647446dc20d66cc53f92e
>
> You can find `iio` in above list.
>
> Build testing in around ~150 or more kernel configs in ~1-2 hours
> And sending the report immediately to the author by bisecting the
> commit on the first failure.
>

Nice! Thanks for all the references and information. I didn't know how
powerful those tests are!

> I don't work for Intel but I have experienced the power of the
> beast ;)
>
> Anyway, for other queries on the development process, I think Rodrigo
> Siqueira can help you too with a quick feedback belonging to the
> same university.
>

Thank you. He's helping me a lot, but regarding Co-Developed-by usage,
he wasn't entirely sure, either, and that's why I asked here. But
Jonathan already helped me.

>
> Thanks!
> --
> Himanshu Jha
> Undergraduate Student
> Department of Electronics & Communication
> Guru Tegh Bahadur Institute of Technology
>

Thanks
Matheus

> --
> You received this message because you are subscribed to the Google Groups "Kernel USP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-usp+unsubscribe@googlegroups.com.
> To post to this group, send email to kernel-usp@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kernel-usp/20181202195617.GB2007%40himanshu-Vostro-3559.
> For more options, visit https://groups.google.com/d/optout.