CAM is not a valid example. It only touched the disk subsystem.
Merging back changes in blocks might not be possible. As Matthew
mentioned, Chuck's experience should be taken for a fact.
And bounding the amount of breakage is almost impossible without
squeezing the people doing the SMP work really badly. I don't think that
that is reasonable.
Nick
> One could argue that you could merge the changes to FreeBSD 5.X on a
> daily or weekly basis to that branch so that the branch doesn't get
> too far out of what. Perforce users do this all the time (cf the cam
> project). The model that I see is that a branch is created for SMP
> work, and that you find a volunteer who has access to SMP machines who
> will merge from current into the SMP branch once a week and boot the
> resulting kernel. If it works, he commits it, otherwise he resovles
> the problems. That way the main developers aren't significantly
> impacted by the merging.
>
> I'd be a lot happier if there was an upper bound on the length of time
> that -current would be unstable, if there was a plan in place on what
> to do if that timelimit was exceeded, if there was a roadmap I could
> look at, etc. Right now the vagueness of it all pushes my panic
> button. I'm trying to get more information so that I know if I should
> just calm down and it won't be that bad, or if I should pitch a huge
> fit because it will be too painful to make progress on any other
> front. Please help me with that.
>
> I'd also be happy if I could create a newcard branch off the last
> stable version of freebsd 5.0-current. That way I could continue my
> work with others and the instability wouldn't matter. All merging, if
> any, would be my responsibility. I don't know what the level of pain
>
> Of course the same arugment about merging you make could be made for
> new kernel work. They will either have to live with the pain (which
> is currently ill-defined at best, knowing what the pain would be would
> help my confort level), or do their work and then redo it on the new
> and improved FreeBSD months later. Why should SMP force others to do
> that?
>
> Warner
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
