Date: Tue, 18 Jun 2002 12:41:05 -0500 From: John Prince <johnp@lodgenet.com> To: Fred Clift <fclift@verio.net> Cc: John Prince <johnp@lodgenet.com>, <stable@FreeBSD.ORG> Subject: Re: ATA Atapi 4.6 Release Message-ID: <5.1.0.14.2.20020618122956.02267258@popmail.ct.lodgenet.com> In-Reply-To: <20020618092610.M32141-100000@vespa.dmz.orem.verio.net> References: <5.1.0.14.2.20020617112839.030a9ff8@popmail.ct.lodgenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=====================_1035723812==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello Fred.. I also want to mention, in our Handbook, last paragraph of section 1.3.3. "In summary, our development model is organized as a loose set of concentric circles. The centralized model is designed for the convenience of the users of FreeBSD, who are thereby provided with an easy way of tracking one central code base, not to keep potential contributors out! Our desire is to present a stable operating system with a large set of coherent application programs that the users can easily install and use, and this model works very well in accomplishing that. " --john At 09:38 AM 6/18/2002 -0600, Fred Clift wrote: >On Mon, 17 Jun 2002, John Prince wrote: > > > > > If not, can someone reply as to why the stability of FreeBSD was > > compromised in favor of an improved method, that does not quite have > > the bugs out of it.. > > >Well, in response to this, I can give you my conjecture. There are >differing viewpoints on what FreeBSD is all about. There are many >different ways to classify FreeBSD users, but for the moment think of them >as 'corporate users' and as 'os developers'. > > From the corporate side, people tend to want predictable release dates, a >very codified, process driven system for handling bugs, 'full' stability, >backward compatibility etc. > >For the developer side, FreeBSD is about doing cool things with the >operating system of your computer. Making things work better/nicer, or >just experimenting etc. > >I would say that over time, the corporate-type people have become more >influential in the project and the world has changed in such a way as to >make 'change' harder. > >It appears that your bias is towards stability at the expense of >innovation (I realize that they need not be not mutually exclusive). >Other's bias is toward getting new features at the expense of some >compatibility. > >In this particular case, the ata-drivers are a two-edged sword. People >want them so they can hot-plug ata devices (especially raid devices), >which the new framework/driver allows. > >One could argue that it might have been better to mfc earlier (ie right >after 4.5-R) or wait till after 4.6-R so that the most time possible for >working out these kinks could be used. I dont know what factors >accompanied the timing of the MFC but I think that if we were going to do >it at all, we just had to pick a time and do it. Never could all the bugs >be worked out between any two releases, even with the most optimal timing, >so if we want the new code at all, we just have to bite the bullet and >work with it. > >Fred > > > >-- >Fred Clift - fclift@verio.net -- Remember: If brute >force doesn't work, you're just not using enough. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-stable" in the body of the message --=====================_1035723812==_.ALT Content-Type: text/html; charset="us-ascii" <html> Hello Fred..<br><br> I also want to mention, in our Handbook, last paragraph of section 1.3.3.<br> "In summary, our development model is organized as a loose set of concentric circles. The centralized model is designed for the convenience of the users of FreeBSD, who are thereby provided with an easy way of tracking one central code base, not to keep potential contributors out! Our desire is to present a stable operating system with a large set of coherent <font color="#0000FF"><u>application programs</u></font> that the users can easily install and use, and this model works very well in accomplishing that.<br> "<br><br> --john<br><br> <br> At 09:38 AM 6/18/2002 -0600, Fred Clift wrote:<br> <blockquote type=cite class=cite cite>On Mon, 17 Jun 2002, John Prince wrote:<br><br> ><br> > If not, can someone reply as to why the stability of FreeBSD was<br> > compromised in favor of an improved method, that does not quite have<br> > the bugs out of it..<br><br> <br> Well, in response to this, I can give you my conjecture. There are<br> differing viewpoints on what FreeBSD is all about. There are many<br> different ways to classify FreeBSD users, but for the moment think of them<br> as 'corporate users' and as 'os developers'.<br><br> From the corporate side, people tend to want predictable release dates, a<br> very codified, process driven system for handling bugs, 'full' stability,<br> backward compatibility etc.<br><br> For the developer side, FreeBSD is about doing cool things with the<br> operating system of your computer. Making things work better/nicer, or<br> just experimenting etc.<br><br> I would say that over time, the corporate-type people have become more<br> influential in the project and the world has changed in such a way as to<br> make 'change' harder.<br><br> It appears that your bias is towards stability at the expense of<br> innovation (I realize that they need not be not mutually exclusive).<br> Other's bias is toward getting new features at the expense of some<br> compatibility.<br><br> In this particular case, the ata-drivers are a two-edged sword. People<br> want them so they can hot-plug ata devices (especially raid devices),<br> which the new framework/driver allows.<br><br> One could argue that it might have been better to mfc earlier (ie right<br> after 4.5-R) or wait till after 4.6-R so that the most time possible for<br> working out these kinks could be used. I dont know what factors<br> accompanied the timing of the MFC but I think that if we were going to do<br> it at all, we just had to pick a time and do it. Never could all the bugs<br> be worked out between any two releases, even with the most optimal timing,<br> so if we want the new code at all, we just have to bite the bullet and<br> work with it.<br><br> Fred<br><br> <br><br> --<br> Fred Clift - fclift@verio.net -- Remember: If brute<br> force doesn't work, you're just not using enough.<br><br> <br> To Unsubscribe: send mail to majordomo@FreeBSD.org<br> with "unsubscribe freebsd-stable" in the body of the message </blockquote></html> --=====================_1035723812==_.ALT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.2.20020618122956.02267258>