Date: Fri, 19 Sep 2008 17:45:52 -0700 From: Jo Rhett <jrhett@netconsonance.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-stable <freebsd-stable@FreeBSD.org>, Lowell Gilbert <freebsd-stable-local@be-well.ilk.org> Subject: Re: Upcoming Releases Schedule... Message-ID: <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> In-Reply-To: <alpine.BSF.1.10.0809191158330.40909@fledge.watson.org> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <F17BE4F1F989BB4A81EB94C36712A9736F3493@dni-mail.datanode.com> <20080904133604.GB1188@atarininja.org> <CB36FE28-D125-4C22-B5DE-1001515DD8A6@netconsonance.com> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <alpine.BSF.1.10.0809061159410.28840@fledge.watson.org> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <alpine.BSF.1.10.0809162043380.64176@fledge.watson.org> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <alpine.BSF.1.10.0809180022580.13100@fledge.watson.org> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <alpine.BSF.1.10.0809181935540.16464@fledge.watson.org> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <C096D142-4572-48DF-8CCA-053B41003A07@netconsonance.com> <alpine.BSF.1.10.0809191158330.40909@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
First, I'd like to thank you for taking the time to respond to this seriously. I hope you'll read my reply in the very serious, and not accusative tone it is meant. (I am a little tired and fried at the moment, I may not use the best phrasing. I hope I do.) On Sep 19, 2008, at 4:20 AM, Robert Watson wrote: > This is the same answer I gave Lowell, but let me expand on it > slightly. Our community grants rights (read also: responsibilities) > on the basis of credibility in the community. Here's a possible plan: ... > work for supported branches. This in turn may convince them that > they should invest their time in mentoring you for a FreeBSD commit > bit, and potentially join the security or release engineering teams > once you've established that you are a member of the developer team > who works well with others, does good technical work, and who is in > it for the long haul. Look, I understand what you're saying here. And I don't discredit or disagree that it shouldn't be handled this way. But what you have addressed is a stepwise integration policy of a developer, and does not address how to get a business to commit those resources. Why? Because you are asking for the business to commit the resources without a goal. No, I'm not saying that FreeBSD has to guarantee anything. We both know that guarantees on open source projects aren't worth much. What I'm saying is that your scoped outline has no goal. Nothing to even reach for. Except maybe perhaps a commit bit for me. If I had wanted a commit bit, I'm sure I would have one by now. I'm not particularly worried about that. I don't even really care to have one (though I would if that was necessary). But that's the highest goal of your outlined scope. A commit bit. What's missing? A. A goal B. An assessment of the requirements to reach that goal ...etc To get a business to commit resources to a project there must be an actual goal. And to reach that actual goal there must be both (a) a plan to get there, (b) a reasoned assessment of the effort involved, etc etc and (z) the effort taking place to reach that goal. Obviously (z) matters and perhaps you can say it matters most. But no sane business tries to do (z) without a clear idea of what (a)(b)(...) is. If you've seen the appropriate Southpark episode: "Step 3: Profit!" "Dude, what's step 2?" > (1) It doesn't give the immediate gratification of seeing the > official support > status extended for releases. However, as you say, you're > already doing > the work. I'm honestly confused by this statement, because I can't imagine anything about the proposed work being "immediate" no matter how it was approached. > and that have they confidence of the security team that will be able > to work with appropriate discretion in protecting the confidential > and often critical security information we receive. Unless the security problem is reported internally within FreeBSD alone (very few problems are) I usually have the security details long before you release patches. I don't see this as much of a hindrance if any. > Don't take this as a personal slight -- none of this says you aren't > able to work with others, that you don't have the technical skills, > that you don't have the time, aren't willing to make the commitment, > or that you lack adequate discretion. Rather, it's saying that the > way we evaluate people for participation in the project is that they > have a track record of these things in the community. In a largely > online and volunteer community, that's the way it works. There's *nothing* wrong with what you have said. What you have said makes perfect sense from an integration perspective. But I don't think it addresses the issues at hand -- businesses need to have explicit goals and at least a haphazard guess at the requirements to reach those goals before they'll commit resources. I don't see these problems as being in conflict. In fact, I would personally suggest that most of the resources you need to improve your releases don't need commit bits. I personally have no objection at all to running all patches through another set (or two, or three) of eyeballs. It's a damn good practice ;-) It's unlikely to slow me down one bit. ^^^ you may know more about the resource limitations and why commit bits are necessary to relieve your resource strain. In that situation, please educate me. Or everyone. In particular, I'll be happy to buy you coffee/beer/poison of choice at your leisure if that would make this easier. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5>