Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Mar 2002 13:26:33 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/kern kern_prot.c
Message-ID:  <200203252126.g2PLQX482425@apollo.backplane.com>
References:   <XFMail.20020325143151.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

:On 23-Mar-2002 dillon@FreeBSD.org wrote:
:>     Is there a reason you made this commit without :
:> 
:>     (1) notifying me and
:
:Err, I was not aware that you wished for explicit notification.
:
:>     (2) not resolving the giant wrappers issue first.
:
:I attempted to do this by working on an instrumentation patch that would
:compromise by allowing the instrumentation code I don't really agree with to be
:in place while still preserving the final code flow of the syscalls, but since
:you demonstrated zero openness to compromise I gave up on it and figured there
:was no reason to waste my time further.
:
:>     And, in fact, my commit would also have gotten getresuid()
:>     and getresgid() out from under Giant, which your commit hasn't
:>     done.
:
:Hmm, I missed merging those changes in.  I'll fix that when I do the suser()
:API change.
:
:-- 
:
:John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/

    Ok, this is long winded but I believe I am able to maintain a 
    relatively civil tongue throughout.

    Though it may not feel that way to you I do consider this a team project.
    It's just that your idea of teamwork is very different from mine.
    I generally don't give a damn who does a commit, as long as the commit
    gets done, but I do care about the timing.   Moving the project forward
    as a whole is what matters most to me, and that infers many things:  It
    infers a certain degree of short-term ownership of material under active
    developmnent.  It infers being able to hold up another developer for a
    short period of time if a conflict arises.  For example, you might
    say to Julian 'Hey Julian, could you hold off your stage X work for
    two days so I can commit Y before my patches become totally unmergable?'.
    Thats reasonable.

    But team work also infers not unnecessarily intefering or stalling
    another developer's work.  You could have held me off for a week if
    you'd asked.  But holding off someone else's work for an arbitrary,
    unspecified period of time, or for trivial reasons (like Jake and his
    tabbing complaints)... that is NOT team work, that is NOT moving the
    project forward, that is simply being selfish.  This project isn't
    about ownership, it's about getting the work done.  This project is
    not about setting things in stone, it's about trying things out.
    It's about being maleable.  

    Perhaps my single largest complaint in regards to your oversight
    is that, as far as I can tell, the entire project is set in stone
    in your head, in P4, and in your documentation.  Direction is useful,
    but being inflexible is detrimental to the project.  This project is
    not about having a single vision.  It was NEVER about having a 
    single vision.

	- 

    In regards to kern_prot.c and critical*().... I think you are missing
    a big point here, John.  Even though you dislike my instrumentation 
    work as much as I dislike the stuff Kelly and you have worked up,
    the fact remains that:

    * It would not have interfered with your work in the least.

    * It was simple, straightforward, and easily removed later on. 
      (my instrumentation work is designed to be easily removed later on!).

      It's not the number of lines of code that makes things easy or 
      difficult here.  I think you've missed this point big time.  Adding
      code with the intention of removing it at some point in the future
      does not somehow make the code useless, or difficult, or improper, or
      an imposition. 

    * You could easily have negotiated its removal a month or two down the 
      line for the read-only ucred bits and it would have been no skin off 
      your nose to let me do the commit 4 weeks ago.  The fact is that my
      giant wrapper is well tested and proven, and here you are trying to 
      stop any work using it in order to, completely from scratch, develop,
      test, and commit a different idea, arbitrarily stalling any sort of
      instrumentation that I am involved in.  That is inappropriate.

    Regardless of the instrumentation, it is now quite clear
    that contrary to all the whining people did when I wanted to commit
    the kern_prot stuff 4 weeks ago, that it would not have effected or
    interfered with your own development efforts in the least.  I repeatedly
    asked people to substantiate their objections and those people, including
    yourself, repeatedly refused to face the issue squarely.  There turned
    out to be no API breakage and no inteference with your own work.

    Consider how little of your time would have been wasted.  I can't 
    imagine it would take more then 10 seconds for you to clean up your
    P4 responsitory to take into accounts the commits I could have made 
    4 weeks and can still make now.  It certainly didn't take me more then
    ten seconds to merge your commit with my kern_prot.c!  All I care about
    is that the work get INTO the tree, I don't care who does it.  I *DO*
    care *WHEN*, however.  Now consider how much of my time you've wasted
    by stalling the development work I was and am keen on doing for over
    4 weeks, as well as unnecessarily stalling testing by the larger
    development community...  I think if you calculate the time lost to
    myself and to the communnity as a whole and time wasted by yourself 
    that you would find that simply allowing the commit 4+ weeks ago 
    would have been the most reasonable course of action.  I am not
    counting flying arguments here, I am simply counting development 
    and testing time lost to the project.

    Even now you appear to be missing the point.  Why not simply allow me
    to commit the getresuid() and getresgid() code today?  Why insist on
    forcing me to wait another unspecified period of time for you to
    include it with other work?  It took you 4 weeks to do a partial commit
    of kern_prot.c, how long is it going to be before you get to
    getresuid()?  

    I mean, come on... either you are going to commit this cleanup today or
    tomorrow yourself, which is perfectly acceptable to me, or you should
    let me do it now. I have it all tested and ready to go in.  What is the
    big problem about not letting me put this work in now?

	-

    When I commit something, it is not set in stone.  I have no problem
    making modifications and follow-up commits.  I prefer to commit things
    piecemeal, because it moves the project forward more quickly and squeezes
    the bugs out more quickly and easily.  But I do take issue with
    core project work being stalled indefinitely for reasons that could just
    as easily be resolved after a commit, and especially for reasons
    that are not substantiated by facts but instead are opinions from
    people who haven't even bothered to read the patch.  From this point
    on I am going to be diplomatic, but firm.  If you have a problem with
    my work I expect it to be (a) non-trivial and (b) substantiated by 
    facts, and if it isn't I will say so in no uncertain terms.  And the
    issue will either be resolved or it will be dropped.

	-

    I am extremely disappointed in core's actions to date.  I have 
    repeatedly asked that these issues be decided on technical merit.
    I have repeatedly asked people to substantiate their claims in
    regards to perceived difficulties with my commits.  Not one person
    has been able to substantiate any claim.  They've all evaporated,
    leaving a minor complaint about syntax and the placement of two
    procedures in MI vs MD files.  All the stuff about interference and
    API breakage... poof, gone.  Because it never existed in the first
    place.

    Instead, Core has made vague statements essentially giving a single
    person VETO power over substantially the entire -current kernel.  I
    would like to see Core clarify this statement in regards to what is
    reasonable and what is not, because under the current terms no
    substantive reason is required for John to veto anything.  Does 
    core actually believe it is reasonable for the technical lead to 
    arbitrarily stall a commit without having to say when it would be
    unstalled?  Or use trivial or unsubstantiated reasons to prevent
    work from going in?  Is 'I don't want this optimized yet' sufficient
    to prevent a developer's work from going into the tree?  Hell, I
    don't even agree with the concept of having a technical lead covering
    so much of the -current kernel.. SMPng *IS* current for all intents and
    puposes.  It touches everything.  A VM lead, or a filesystem lead, or
    a SCSI lead... sure.  But SMPng?  It makes no sense at all.  All the
    big pieces are either already in place or well enough defined that
    development progresses pretty much under its own steam now.  

    The position is already not relevant to development (and I'm not talking
    about my own development here, I am talking about ALL the development
    that is going on).  Case in point:  Jeff's UMA work requires discussion
    but certainly does not require a technical lead.  Julian's work
    requires discussion but not a SMPng technical lead.  Julian is
    effectively his own technical lead for KSEs.  VM work is a group
    effort, requiring discussion but not requiring a technical lead.
    I can't think of a single major subsystem that requires a SMPng 
    technical lead.  It was an ill-thought, ill-conceived notion of core's.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203252126.g2PLQX482425>