Re: linux-next: Tree for Jun 23

[Eric W. Biederman]

Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes:

> On Tue, Jun 23, 2015 at 05:53:58AM -0500, Eric W. Biederman wrote:
>> 
>> Stephen could you please drop the kdbus tree?
>
> What?  No, that's not how this works.  That's not how any of this
> works.

That is exactly how this works.  Unless there was a change in policy
that I missed linux-next is for code that is planned to be sent to Linus
in the coming merge window.  The purpose of linux-next is to
preemptively detect merge issues between trees.  As a bonus a the trees
also get a little bit of build and merge testing.

Frankly given how far kdbus has to go I was rather appalled when I
noticed that the code was sitting in linux-next.

>> There was some significant work that was identified last merge window
>> that has not yet been done, and who knows when it will be done.
>> Certainly the recent sd-bus API announcement strongly suggests that
>> there are no plans to perform such work.
>> 
>> Having the kdbus tree in linux-next with the implicit suggestion that a
>> pull request will be sent to Linus this merge window before the problems
>> are addressed and we will have to repeat the mess from last merge window
>> keeps me up at night.
>
> Code sitting in linux-next keeps you awake?  I think you need to
> exercise more so that you can sleep better :)

Having to use the most forceful language I know to tell people I respect
that their judgment is faulty is very unpleasant for me.

The code sitting in linux-next makes it appear that nothing has
substantively changed since the last merge window.  That we will have to
repeat the mess that happened last merge window.  That is not productive
for anyone.

>> So to avoid the appearance that the kdbus folks are continuing to
>> ignoring feedback can we please keep the kdbus tree out of linux-next
>> until it is ready to be merged?
>
> We are not ignoring _constructive_ feedback, please realize the
> difference.

I don't truly know what the plans are for kbus.   I do know that there
is the appearance that some of the constructive feedback has not been
acted upon.    I have yet to see a fast userspace dbus implementation for
comparison purposes or hear a rumor of one.  The action with publishing
sd-bus with non-optional kdbus support locks in the kdbus-ioctl API
which means that the ioctl numbers will now need to change if any kernel
api changes are required.   I know of at least one piece of criticism
that once acted upon will require changing the userspace api, and I
suspect several other pieces of constructive criticism will as well.

> First Andy does a preemptive NAK of a pull request that was never sent,
> and now you want to kick it out of linux-next for no valid reason.  If I
> was an insecure person, I'd think that there are some people in the
> kernel community who don't like me at the moment.

I was asking that the tree leave linux-next because it does not
represent code that is likely (or should at this point) be sent to Linus
this merge window.  Last I checked that was a valid reason to keep code
out of linux-next.

> This is just getting ridiculous.

This has been ridiculous for a long time.

There has been times in this process where ignoring constructive
feedback has been the norm.  There have been times in this process where
a word to the wise about technical issues has been the norm.  I have
little evidence that things are better.

All that I have evidence for, is that the conversations have gone silent
and some minor issues to kbus have been addressed.

The appearance is that the constructive feedback has been blown off and
that with kdbus sitting in linux-next you are preparing a pull request
to Linus this merge window.

So to remain the appearance of propriety, I am asking that kdbus be
removed from linux-next until the code is in a state where asking for
the code to be merged will not be controversial.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/