From: Greg KH <greg@kroah.com>
To: wuzhouhui <wuzhouhui14@mails.ucas.ac.cn>
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: Fwd: Re: [GIT PULL] PCI changes for v5.12
Date: Fri, 26 Feb 2021 11:09:51 +0100 [thread overview]
Message-ID: <YDjI77DWBg5MFNdq@kroah.com> (raw)
In-Reply-To: <553ed469-4f75-e14b-f344-685ae7a955bf@mails.ucas.ac.cn>
On Fri, Feb 26, 2021 at 06:02:07PM +0800, wuzhouhui wrote:
> On 2/26/21 3:07 PM, Greg KH wrote:
> > On Fri, Feb 26, 2021 at 12:54:16PM +0800, wuzhouhui wrote:
> > > I'm confused about what the Linus said. It seemed that the branch cannot
> > > be rebased after merged into linux-next under normal circumstances, why?
> > You should never rebase a public-facing branch.
> >
> > > Linus found this issue by check commit time of commits, but I also found so
> > > many commit in mainline are too young to be merged into linux-next before
> > > merge to mainline. If the rebase is not recommended, why people like to
> > > do rebase after commits are merged into linux-next?
> > What commits have you found, and are you sure those are not just merged
> > through email submissions to Linus instead of a git tree pull? Please
> > note that some subsystems still use email, like Andrew Morton's.
> Following commit log are copied from mainline
>
> 14 hours Merge tag 'pwm/for-5.12-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git...HEADmaster Linus
> Torvalds 7 -374/+65
> 14 hours Merge tag 'for_linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost Linus Torvalds
> 22 -507/+1492
> 14 hours Merge tag 'mips_5.12_1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mips... Linus Torvalds
> 8 -5/+190
> 14 hours Merge tag 'drm-next-2021-02-26' of
> git://anongit.freedesktop.org/drm/drm Linus Torvalds 68 -423/+1223
> 14 hours Merge tag 'net-5.12-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/net... Linus Torvalds
> 68 -371/+734
> 14 hours Merge tag 'acpi-5.12-rc1-3' of
> git://git.kernel.org/pub/scm/linux/kernel/git/... Linus Torvalds 8
> -27/+334
Take a look at these and think about why they couldn't be in linux-next
beforehand :)
You might want to look at non-merge commits...
> 16 hours net: phy: micrel: set soft_reset callback to genphy_soft_reset
> for KSZ8081 Christian Melki 1 -0/+1
> 16 hours Merge tag 'nds32-for-linux-5.12' of
> git://git.kernel.org/pub/scm/linux/kernel... Linus Torvalds 4 -50/+5
> 16 hours net: psample: Fix netlink skb length with tunnel info Chris
> Mi 1 -2/+2
> 16 hours net: broadcom: bcm4908_enet: fix NAPI poll returned value
> Rafał Miłecki 1 -0/+2
> 16 hours net: broadcom: bcm4908_enet: fix RX path possible mem leak
> Rafał Miłecki 1 -0/+1
>
> We can see that, last non-merge commit is just 2 hours older than
> merge-commits committed
> by Linus, so these non-merge commits shouldn't contained in linux-next
> before merge into
> mainline. Does me misunderstand something?
For bugfixes, yes, they can be accepted now for "high volume" subsystems
like networking. You don't want those to be delayed, especially when
they are found to be fixes in the previous pull request for that
subsystem, right?
But what we do not want is a bunch of "quick, let's rebase our patches
on Linus's latest tree!" for normal commits as then we have no idea if
they really were tested out in linux-next or not.
thanks,
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
prev parent reply other threads:[~2021-02-26 10:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHk-=wiUjFdHYxQzTPJX+J38iSz-hS8Sn9sNx=+B=uMX+Q3wwQ@mail.gmail.com>
2021-02-26 4:54 ` Fwd: Re: [GIT PULL] PCI changes for v5.12 wuzhouhui
2021-02-26 7:07 ` Greg KH
2021-02-26 10:02 ` wuzhouhui
2021-02-26 10:09 ` Greg KH [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=YDjI77DWBg5MFNdq@kroah.com \
--to=greg@kroah.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=wuzhouhui14@mails.ucas.ac.cn \
/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 NNTP newsgroup(s).