On Mon, 12 Jan 2004, Mark Linimon wrote: > > If nothing happens, vinum is going to break even more very soon. > > No ... if you do a commit that changes the code assumptions upon which > vinum was built, vinum will break. vinum is not going to "magically" > break by itself. > > This gets back to a problem with the FreeBSD development model: people > who commit changes that break things in other parts of the system do not > automatically get assigned the responsibility to fix them. Now, there's > no way to impose something like that requirement on a cooperative > anarchy, so I am not playing the "let's reorganize" card -- I think > most of us would agree that "that dog won't hunt" as we say down around > these parts. > > But, in the real world of software engineering, He Who Breaketh It, Must > Fixeth It.
Well, actually, it's not quite that way. The reality is that every major component in a system needs someone with expertise in it, who is willing and available to maintain the system across infrastructural changes. Vinum has made it over smaller API bumps without a maintainer: the move to devfs, etc. However, to make it speak GEOM requires someone highly familiar with Vinum, and with the time available to do it. If we want to enhance the architecture of FreeBSD for improvements in performance, stability, and long-term maintainability, there will necessarily be structural changes that require a distributed update of the system. FreeBSD is of sufficient size that no one person will be able to make this sort of change alone, which is one of the important reasons to have a software maintenance model that reflects that. Our notion of software maintainance could certainly use some further evolution, but I think there are some existing intuitions. Vinum is a highly complex software module, and *must* have an active maintainer in order to survive structural operating system changes. Greg has recently posted to arch@ saying "What's the future of Vinum", indicating an intent to continue to enhance Vinum, and received a number of e-mails regarding how to adapt Vinum for GEOM. I sent him an e-mail in which I laid out a spectrum of possibilities, ranging from the minimalist to a complete transformation of Vinum into a GEOM module. Greg has indicated he plans to work on Vinum further, so I think the best we can do is provide support and encourgement. The minimalist approach appears to be viable (although there are some risks), and someone highly familiar with Vinum (such as Greg) can probably make the changes in short order. He's currently at a conference, but my hope is that when he gets back, he'll evaluate some of the approaches we've described, and pick one. I think the right strategy is to follow the minimalist approach now (adopt the disk(9) API, rather than having Vinum generate character devices) so that swap works on Vinum again, and so that when UFS moves to speaking GEOM there's no loss of functionality. If we want to completely reimplement Vinum, we should do that separately so as to avoid loss of functionality during structural changes. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"