Date: Tue, 20 Jun 2000 13:27:03 -0600 From: Warner Losh <imp@village.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Jason Evans <jasone@canonware.com>, current@FreeBSD.ORG Subject: Re: HEADS UP: Destabilization due to SMP development Message-ID: <200006201927.NAA71421@harmony.village.org> In-Reply-To: Your message of "Tue, 20 Jun 2000 12:20:29 PDT." <200006201920.MAA87999@apollo.backplane.com> References: <200006201920.MAA87999@apollo.backplane.com> <20000619115330.D79318@blitz.canonware.com> <200006201833.MAA70626@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200006201920.MAA87999@apollo.backplane.com> 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 that? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006201927.NAA71421>