From: Patrick Williams <patrick@stwcx.xyz>
To: Joel Stanley <joel@jms.id.au>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
Delphine_CC_Chiu/WYHQ/Wiwynn <Delphine_CC_Chiu@wiwynn.com>
Subject: Re: [PATCH linux dev-6.5 v4 0/2] LTC4286 and LTC4287 driver support
Date: Tue, 12 Dec 2023 15:43:06 -0600 [thread overview]
Message-ID: <ZXjT6lVuXZUqhfIQ@heinlein.vulture-banana.ts.net> (raw)
In-Reply-To: <CACPK8XdGnc44AMtOWoz22BNw-JRG3sF+e9W8wQSt=1FajzvsRw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]
Hello Joel,
On Tue, Dec 12, 2023 at 12:42:18PM +1030, Joel Stanley wrote:
> I have some
> new rules for getting the patches merged into openbmc:
Can you please update this wiki with what your current expectations are
then because these are not obviously reflected:
https://github.com/openbmc/linux/wiki/DevelopmentProcess
> 1. Do not send them for backporting to the dev-6.6 branch until they
> have been reviewed upstream. This means you have Reviewed-by or
> Acked-by tags on at least a majority of the patches in a series before
> you send them to the openbmc list.
> 2. Find reviewers for your upstream patches. Get other Facebook
> employees, get other openbmc contributors to review your patches. A
> good way to encourage others to review your patches is to first review
> thiers.
The submitters here are not Facebook employees (nit: there is also no such
thing as the company changed names 2 years ago now), but they are doing
work partially on behalf of Meta as their company is partnering with us to
develop new systems.
In this case, I don't think review has been an issue since Guenter
applied v7 to his tree.
> 3. When you do send the patches for backporting, include a
> justification in the cover letter for why they should be backported.
> For example: "These patches are merged upstream" or "the changes under
> active review, but we wish to have them in the openbmc tree because it
> has been ongoing for more than two weeks".
It would be nice for the wiki to give clear unbiased criteria here.
Currently it says:
Patches for pre-upstream inclusion ... should be at least of a level
approximately ready to submit upstream.
This implies, by my reading, that any commit sent upstream can in
parallel be sent to our 'dev-*' branches, since that is a stronger
criteria than you've listed.
Anyone can carry patches in their own downstream trees, so it isn't
obvious to me when it is deemed beneficial and not a burden to also
request a backport to the openbmc/linux branches. I get the impression
that our backports requests are more on the burden end of the spectrum.
> Your latest upstream patchset produces a large number of warnings when
> I applied it to the 6.7-rc1 tree. This shows you are not compiling
> your changes before submitting.
>
> Please engage with me and the other developers on this issue so we can
> help each other get the changes up to scratch and merged.
>
> Cheers,
>
> Joel
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2023-12-12 21:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 8:20 [PATCH linux dev-6.5 v4 0/2] LTC4286 and LTC4287 driver support Delphine CC Chiu
2023-11-08 8:20 ` [PATCH linux dev-6.5 v4 1/2] dt-bindings: hwmon: Add lltc ltc4286 driver bindings Delphine CC Chiu
2023-11-08 8:20 ` [PATCH linux dev-6.5 v4 2/2] hwmon: pmbus: Add ltc4286 driver Delphine CC Chiu
2023-11-08 11:21 ` [PATCH linux dev-6.5 v4 0/2] LTC4286 and LTC4287 driver support Joel Stanley
2023-11-10 2:35 ` Joel Stanley
2023-11-15 8:53 ` Delphine_CC_Chiu/WYHQ/Wiwynn
2023-12-12 2:12 ` Joel Stanley
2023-12-12 21:43 ` Patrick Williams [this message]
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=ZXjT6lVuXZUqhfIQ@heinlein.vulture-banana.ts.net \
--to=patrick@stwcx.xyz \
--cc=Delphine_CC_Chiu@wiwynn.com \
--cc=joel@jms.id.au \
--cc=openbmc@lists.ozlabs.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).