From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 1 18:18:31 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 9353E106564A; Wed, 1 Aug 2012 18:18:31 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B9F018FC0C; Wed, 1 Aug 2012 18:18:30 +0000 (UTC) Received: by laai10 with SMTP id i10so5864706laa.13 for ; Wed, 01 Aug 2012 11:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=G58ahDoqZx5DAM/xsRJp7ktRMO8AKxr+HV1yF2sEYL8=; b=LbQyQ+O4fpqVqC9+QBBoS0ZSV6C8NaNedi+86kFrLtvycOjkKhSyWglcW8bj6Ygyms UxhujsG9T5zf0LPOF7H/2axRe2j7d7YYLncBujD/I9723K4ZtlNzy27AMtXL375Gjaqs 721YD7wwmFf+exivBRfFW4QLIEGXbnUmV8Y/gRAf93E7tSTwWx7TjVDCzy2SdZAjjqqE P361NSdbShx/LUciv8habDMX0GwoLD78tbmml5i6Su/PX2WTcTubpsAj8Dk96Xv2wnGK i75He9Ak94orpcrpk3QPaFCKv6xFkL1aqiXxp5UNGKRyZqjQRu6ImcQprIK3+y2MDows 9QbQ== MIME-Version: 1.0 Received: by 10.112.42.34 with SMTP id k2mr8582422lbl.0.1343845109200; Wed, 01 Aug 2012 11:18:29 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Wed, 1 Aug 2012 11:18:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 19:18:28 +0100 X-Google-Sender-Auth: cO2Hq5cflnC0rxHVHrVm193MuaU Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 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 Reply-To: attilio@FreeBSD.org 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 18:18:31 -0000 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, 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. > 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. >> 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? >> 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. Attilio -- Peace can only be achieved by understanding - A. Einstein