* Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote:
> On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> > * Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> > > Hi Josh,
> > >
> > > Today's linux-next merge of the tiny tree got a conflict in
> > > kernel/time/Makefile between commit fd866e2b116b ("time: Rename
> > > udelay_test.c to test_udelay.c") from the tip tree and commit
> > > d1f6d68d03ea ("kernel: time: Compile out NTP support") from the tiny
> > > tree.
> >
> > So I think a timer subsystem commit d1f6d68d03ea with this
> > magnitude of linecount increase:
> >
> > Signed-off-by: Catalina Mocanu <catalina.mocanu@xxxxxxxxx>
> > [josh: Handle CONFIG_COMPAT=y.]
> > Reviewed-by: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
> > ---
> > drivers/pps/Kconfig | 2 +-
> > include/linux/timex.h | 15 +++++++++++++--
> > init/Kconfig | 10 ++++++++++
> > kernel/compat.c | 8 ++++++--
> > kernel/sys_ni.c | 4 ++++
> > kernel/time/Makefile | 3 ++-
> > kernel/time/ntp_internal.h | 28 ++++++++++++++++++++++++++++
> > kernel/time/posix-timers.c | 2 ++
> > kernel/time/time.c | 2 ++
> > kernel/time/timekeeping.c | 2 ++
> > 10 files changed, 70 insertions(+), 6 deletions(-)
> >
> > at minimum needs the ack of timer folks, before it can be
> > committed to Git. Or is the tiny tree plan to submit all
> > patches to the appropriate subsystem or gather acks, before
> > sending it upstream?
>
> Yes, absolutely. I planned to send out a tinification patch
> review series later this week with all 10 current patches (both
> those reviewed on LKML and those only reviewed elsewhere).
But, but: _please_ don't push patches towards linux-next that
haven't been acked by maintainers.
The point of linux-next is to expose subsystem trees that are
likely to go upstream in the next release - generally because the
maintainers themselves push it out, but sometimes also when
there's acked patches (or features) from maintainers that get
collected in other trees by developers (such as yours).
But unacked patches with clear problems, causing conflicts, is
outside that scope. If you want coverage testing you can push it
out to korg into your own tree, then Fengguang Wu's robot will
pick it up and report problems with it.
In other words: pushing linux-tiny to linux-next is fine, but
only for patches that got acked by maintainers and is lined up
for the next release. For 'work in progress' patches, other
venues such as korg should be used.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
