[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging Net/Free/Open-BSD together against Linux
[ 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!
toddpw @ best.com