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.


> 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]                                          USB project

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to