In message <[EMAIL PROTECTED]> Matthew Dillon writes:
:     The problem is that the changes are simply too extensive to be able
:     be able to split them off then merge them back into 5.x N months later.
:     Creating another branch will tripple the workload on anyone doing 
:     merge work.

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


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

Reply via email to