From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 1 19:45:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FBCE106564A; Wed, 1 Aug 2012 19:45:38 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5758FC0A; Wed, 1 Aug 2012 19:45:37 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so7004548wgb.31 for ; Wed, 01 Aug 2012 12:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SzedmssDr5OQGcpPEtLAFzoUsa7MPo7YTp08DpRTa7Q=; b=bAvtTEHO0SQ2UNPmaOC1FObfNACRfdwp+kVbnRLWieJQqs+c4jpFtHxybyB4lQkY94 BJBmT7IVZ7T1NTKSqBTIloMVPpZPt1ZwCBVqVCAT6RoFGolN8/3tJObIqpBM+L4Ai6ur VfhVdFzrBAZr7xym8cqUev27PVt0wkOBCsLiaQ3e1A+03qlHqdyvqVQTaHc0UFbSpmSy vPedIQZ63Ji1scIsk2Zsi5kcRru1T14se1B0VGcv/Rt693iYEKa/tVDk6fyS0ScppQ4d 7SXvbLepA90498wa6kqV5+AotIEwMqysumtghTTMEx3MKtDKzidx9Eo5azJwGlDZs5UA vFmw== MIME-Version: 1.0 Received: by 10.180.81.66 with SMTP id y2mr18959943wix.22.1343850335435; Wed, 01 Aug 2012 12:45:35 -0700 (PDT) Received: by 10.216.140.155 with HTTP; Wed, 1 Aug 2012 12:45:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 15:45:35 -0400 Message-ID: From: Arnaud Lacombe To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 19:45:38 -0000 Hi, On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: > On 8/1/12, Arnaud Lacombe wrote: >> Hi, >> >> On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >>> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe >>> wrote: >>>> Hi, >>>> >>>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao >>>> wrote: >>>>> >>>>> You don't want to work cooperatively. >>>>> >>>> Why is it that mbuf's refactoring consultation is being held in >>>> internal, private, committers-and-invite-only-restricted meeting at >>>> BSDCan ? >>>> >>>> Why is it that so much review and discussion on changes are held >>>> privately ? >>> >>> Arnaud, >>> belive me, to date I don't recall a single major technical decision >>> that has been settled exclusively in private (not subjected to peer >>> review) and in particular in person (e-mail help you focus on a lot of >>> different details that you may not have under control when talking to >>> people, etc). >>> >> Whose call is it to declare something worth public discussion ? No one. >> >> Every time I see a "Suggested by:", "Submitted by:", "Reported by:", >> and especially "Approved by:", there should to be a public reference >> of the mentioned communication. > > Not necessarilly. Every developer must ensure to produce a quality > work, with definition of "quality" being discretional. Some people > fail this expectation, while others do very good. As a general rule, > some people send patches to experts on the matter and they just trust > their judgment, others also full-fill testing cycles by thirdy part > people, others again ask for public reviews. Often this process is > adapted based on the dimension of the work and the number of > architectural changes it introduces. > > As a personal matter, for a big architectural change things I would > *personally* do are: > - Prepare a master-plan with experts of the matter > - Post a plan (after having achived consensus) on the public mailing > list for further discussions > - Adjust the plan based on public feedbacks (if necessary) > - Implement the plan > - Ask the experts if they have objections to the implementation > - Ask testers to perform some stress-testing > - Ask testers to perform benchmark (if I find people interested in that) > - Send out to the public mailing list for public review > - Integrate suggestions > - Ask testers to stress-test again > - Commit > > I think this model in general works fairly well, > I agree. > but people may have > different ideas on that, meaning that people may want to not involve > thirdy part for testing or review. This is going to be risky and lower > the quality of their work but it is their call. > >>> Sometimes it is useful that a limited number of developers is involved >>> in initial brainstorming of some works, >>> >> Never. >> >>> but after this period >>> constructive people usually ask for peer review publishing their plans >>> on the mailing lists or other media. >>> >> Again, never. By doing so, you merely put the community in a situation >> where, well, "We, committers, have come with this, you can either >> accept or STFU, but no major changes will be made because we decided >> so." > > You are forgetting one specific detail: you can always review a work > *after* it entered the tree. This is something you would never do, but > sometimes, when poor quality code is committed there is nothing else > you can do than just raise your concern after it is in. > Unfortunately, not. First, the developer will certainly have moved on after the commit, API may have been changed tree-wide, etc. Then, time is likely to have passed between the time you figure potential regression or bugs, which makes the first point even more problematic. Finally, if my point of view is being ignored *before* it goes to the tree, do you really expect it will be considered *after* ? >From my external point of view, committers not only have the possibility, but *do* commit mess in the tree without non-committers could say or do anything, just as well as committers being able to arbitrarily close PR even if the original reporter disagree. >> The callout-ng conference at BSDCan was just beautiful, it was basically: >> >> Speaker: "we will do this" >> Audience: "how about this situation ? What you will do will not work." >> Speaker: "thank you for listening, end of the conference" >> >> It was beautiful to witness. > > Not sure if you realized but I was what you mention "Audience". I > think you are referring to a specific case where a quick heads-up on a > summer of code project has been presented, you cannot really believe > all the technical discussion around FreeBSD evolve this way. > indeed, but that was still the case back then. >>> If you don't see any public further discussion this may be meaning: >>> a) the BSDCan meetings have been fruitless and there is no precise >>> plan/roadmap/etc. >>> >> so not only you make it private, but it shamelessly failed... > > And so? I think you have a wrong point of view of what is > shamelessly... I'm working on the same project since 6 months, i > thought I could finish it in 1 but then I understood that in order to > get the quality I was hoping I had to do more work... does it qualify > as failed, according to your standard? > not specifically, but at the end of that project of your, I would run a post-mortem meeting to see what went correctly and where things got out-of-control. As for the mbuf meeting, all I can find from it online is: http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html which is not worth much... Rather than doing things internally, maybe it is time to open up... oh, wait, you will certainly come to the community with a design plan, figure out it's not gonna work while doing the implementation, change the design plan while implementing, go public with a +3k/-2k loc change patch, ask for benediction, go ahead and commit it up until someone comes with an obvious design flaw which would render the change pretty much useless, but there will be man-month of work to fix it, so it's never gonna be done. One obvious problem in FreeBSD is that committers are prosecutor, judge and jury altogether. That's not the first time I point this out. >>> b) there is still not consensus on details >>> >> Then the discussion should stop, public records are kept for reference >> in the future. There is no problem with this. >> >>> and you can always publically asked on what was decided and what not. >>> Just send a mail to interested recipients and CC any FreeBSD mailing >>> list. >>> >> This is not the way "openness" should be about. > > There is not much more you can do when people don't share details and > discussions automatically. > keep reporting regressions, interface flaws, POLA violations, ABI breakages, bugs, etc. - Arnaud