Patches and review process

[Diego Rondini]

Hi Stefano,

I'd like to kindly ask the status of two patches:
a) swupdate-image: remove image_types_uboot image class
b) swupdate: use sysconfdir variable
I don't want to put pressure on anyone, just to know if they are being
considered.


In addition, as swupdate is growing as a community project, I'd like to
propose to adopt some kind of patch tracking & management tool like for
example:
1) patchwork ~ http://jk.ozlabs.org/projects/patchwork/
2) Github pull request ~ https://help.github.com/articles/about-pull-requests/
(Pull Request mailing list integration ~ https://github.com/google/pull-request-mailer )
Of course both are different approaches, the first just being a useful
companion to the mailing list patch submission process, the second having its
own workflow, but both have their own advantages.
I'd like to know Stefano's and other people's opinion about the topic, or if
you feel such a tool is not needed.

Bests,
Diego Rondini
Sr. Embedded Engineer

Kynetics
www.kynetics.com

[Stefano Babic]

Hi Diego,

On 01/08/2017 12:33, Diego Rondini wrote:
> Hi Stefano,
>
> I'd like to kindly ask the status of two patches:
> a) swupdate-image: remove image_types_uboot image class
> b) swupdate: use sysconfdir variable
> I don't want to put pressure on anyone, just to know if they are being
> considered.

I missed them, I will take a look.

>
>
> In addition, as swupdate is growing as a community project, I'd like to
> propose to adopt some kind of patch tracking & management tool like for
> example:

Up now I avoided to add overhead because the number of patches and users
was limited - I agree that using a tool is a help (first at all, for
me...). I am starting to miss some patches if I have no time to review
them at the time they are sent.

> 1) patchwork ~ http://jk.ozlabs.org/projects/patchwork/

I am already using it as U-Boot (i.MX) maintainer. The disadvantages are
some missing features that are more important in a large project as
U-Boot. First, Patchwork does not recognize versions of patches. I would
like to have a mechanism that set an old version as obsolete (or put the
series into "change requested") without having to search manually for
all versions.

On the other side, patchwork recognizes tags and adds automatically
"Acked-by" or "Reviewed-by" to the resulting patch.

Using pwclient is a comfortable way to merge patches and to run
automatic tests for CI - but again, some important features are missing
(for example, "pwclient -d" does not work with many maintainers as in
U-Boot).

Anyway, as patchwork requires to me quite no effort to use it, it is my
first choice. But who will host it ? Could be on http://jk.ozlabs.org ?

> 2) Github pull request ~ https://help.github.com/articles/about-pull-requests/
> (Pull Request mailing list integration ~ https://github.com/google/pull-request-mailer )

I have *explicitely* disabled PR and "Issues" on Github for SWUpdate and
meta-swupdate. My workflow is based on mails (text), and I won't use a
Web Interface just for it.

> Of course both are different approaches, the first just being a useful
> companion to the mailing list patch submission process, the second having its
> own workflow, but both have their own advantages.
> I'd like to know Stefano's and other people's opinion about the topic, or if
> you feel such a tool is not needed.

Best regards,
Stefano

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Diego Rondini]

Hi Stefano,

On martedì 1 agosto 2017 13:27:25 CEST Stefano Babic wrote:
> Hi Diego,
>
> On 01/08/2017 12:33, Diego Rondini wrote:
> > Hi Stefano,
> >
> > I'd like to kindly ask the status of two patches:
> > a) swupdate-image: remove image_types_uboot image class
> > b) swupdate: use sysconfdir variable
> > I don't want to put pressure on anyone, just to know if they are being
> > considered.
>
> I missed them, I will take a look.

Thanks.

>
> > In addition, as swupdate is growing as a community project, I'd like to
> > propose to adopt some kind of patch tracking & management tool like for
>
> > example:
> Up now I avoided to add overhead because the number of patches and users
> was limited - I agree that using a tool is a help (first at all, for
> me...). I am starting to miss some patches if I have no time to review
> them at the time they are sent.

It also helps us submitters to keep track of status of our patches.

>
> > 1) patchwork ~ http://jk.ozlabs.org/projects/patchwork/
>
> I am already using it as U-Boot (i.MX) maintainer. The disadvantages are
> some missing features that are more important in a large project as
> U-Boot. First, Patchwork does not recognize versions of patches. I would
> like to have a mechanism that set an old version as obsolete (or put the
> series into "change requested") without having to search manually for
> all versions.
>

I think patchwork supports new patch version / new series version, but
requires submitters self-discipline:
http://patchwork-freedesktop.readthedocs.io/en/latest/manual.html#new-patch
Maybe you could just remind about "--reroll-count" to "new-guy-in-town"
submitters, when asking for updated patches / patchset. A mention in the
"Submitting patches" READMEs section would not hurt either.

> On the other side, patchwork recognizes tags and adds automatically
> "Acked-by" or "Reviewed-by" to the resulting patch.
>
> Using pwclient is a comfortable way to merge patches and to run
> automatic tests for CI - but again, some important features are missing
> (for example, "pwclient -d" does not work with many maintainers as in
> U-Boot).
>
> Anyway, as patchwork requires to me quite no effort to use it, it is my
> first choice. But who will host it ? Could be on http://jk.ozlabs.org ?

I didn't find instruction or policies about being included in:
http://patchwork.ozlabs.org/
but seeing the number and variety of OSS projects there I think the host is at
least open to the possibility of including new projects.
I see no advantage of hosting our own patchwork. Also having other projects
(like U-Boot) already there means less register / login duplication.

>
> > 2) Github pull request ~
> > https://help.github.com/articles/about-pull-requests/ (Pull Request
> > mailing list integration ~ https://github.com/google/pull-request-mailer
> > )
> I have *explicitely* disabled PR and "Issues" on Github for SWUpdate and
> meta-swupdate. My workflow is based on mails (text), and I won't use a
> Web Interface just for it.
>

Github can be managed with command line git too, but I have nothing to sell,
so I'm fine with what you feel comfortable with!

[Stefano Babic]

Hi Diego,

You can forget it. We tried some years ago with U-Boot, asking to
reply-in-thread because it was the best way for patchwork. None result.

And frankly, I cannot set high and strange rules to people willing to
contribute to the project.

> when asking for updated patches / patchset. A mention in the
> "Submitting patches" READMEs section would not hurt either.
>
>
>> On the other side, patchwork recognizes tags and adds automatically
>> "Acked-by" or "Reviewed-by" to the resulting patch.
>>
>> Using pwclient is a comfortable way to merge patches and to run
>> automatic tests for CI - but again, some important features are missing
>> (for example, "pwclient -d" does not work with many maintainers as in
>> U-Boot).
>>
>> Anyway, as patchwork requires to me quite no effort to use it, it is my
>> first choice. But who will host it ? Could be on http://jk.ozlabs.org ?
>
> I didn't find instruction or policies about being included in:
> http://patchwork.ozlabs.org/
> but seeing the number and variety of OSS projects there I think the host is at
> least open to the possibility of including new projects.
> I see no advantage of hosting our own patchwork.

This is why I asked - I have no interest in hosting it.

> Also having other projects
> (like U-Boot) already there means less register / login duplication.

I sent the question to Jerry.

>
>>
>>> 2) Github pull request ~
>>> https://help.github.com/articles/about-pull-requests/ (Pull Request
>>> mailing list integration ~ https://github.com/google/pull-request-mailer
>>> )
>> I have *explicitely* disabled PR and "Issues" on Github for SWUpdate and
>> meta-swupdate. My workflow is based on mails (text), and I won't use a
>> Web Interface just for it.
>>
>
> Github can be managed with command line git too, but I have nothing to sell,
> so I'm fine with what you feel comfortable with!
>