Date: Sun, 29 Nov 1998 23:21:27 -0800 (PST) From: Todd Whitesel <toddpw@best.com> To: adrian@ubergeeks.com Cc: toddpw@best.com, grog@lemis.com, art@stacken.kth.se, alicia@internetpaper.com, netbsd-advocacy@NetBSD.ORG, FreeBSD-advocacy@FreeBSD.ORG, advocacy@openbsd.org Subject: Re: Merging Net/Free/Open-BSD together against Linux Message-ID: <199811300721.XAA04398@shell17.ba.best.com> In-Reply-To: <Pine.BSF.3.96.981129162602.867B-100000@lorax.ubergeeks.com> from ADRIAN Filipi-Martin at "Nov 29, 98 04:40:58 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[ Followups to private email please. ] > > Provide a tree that people can use to merge individual userland programs, > > and publish status reports on how each individual program is doing: whether > > it is unified, and which of the 3 projects has adopted the unified version. > > This is a valid approach. But I think it has more logistical > problems. Do all three BSD's maintain identicle copies of the source in > their CVS repositories? This somewhat complicated. Check-in's are > multiplied three fold. diff+patch check-ins are politically very cheap. To paraphrase your original description, the work is technically quite boring, just time intensive. That is the main reason why it has not been getting done; otherwise I think most everyone agrees that nonconflicting changes should be merged across all BSDs. > It makes more sense in my mind to have a single repository for > working this out. If not an independent repository, then at the very > least a branch off one repository. Then each camp as they see fit could > drop /usr soruces and rely upon the unified versions. A single repository for working things out, yes. But a single unified userland tree that each BSD has to switch to in toto? I don't think so. That really is likely to create a fourth BSD, or end up folded back into the one BSD whose userland you started with. I repeat, make your unit of progress (for now) be the individual programs in userland. It's technically non-difficult to take three similar programs ported to different BSD's, and merge them into one unified program that is ported to all *BSD's. Such a program is very easy to justify checking in at all three projects. Please have faith in this process, because it will bring you far more success than trying to "fix" how the *BSD's are doing things. They will not change, not because of big egos, but rather because they have solid convictions in the correctness of their policies, given the respective goals that they have set for themselves. Before you can tackle the difficult aspects of merging userlands, or even (gasp) the driver API's or other kernel issues, you MUST have a good set of working relationships between the various core teams and the merge team. The absolute best way to cultivate this is to start with small forward steps. The main reason we don't want to repeat what happened with EGCS is that for most of GCC's user base, GCC is a drop-in component. Userland as a whole is definitely not a drop-in component, at least not if you expect it to work! Todd Whitesel toddpw @ best.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811300721.XAA04398>