Date: Wed, 8 Mar 2006 13:23:51 -0500 From: Garance A Drosehn <gad@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com>, scottl@samsco.org Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/vm swap_pager.c vm_fault.c vm_map.c vm_page.c vm_pageq.c Message-ID: <p06230922c034c40373f2@[128.113.24.47]> In-Reply-To: <20060308.090211.97454770.imp@bsdimp.com> References: <20060307.233728.42821161.imp@bsdimp.com> <20060308092207.GB679@turion.vk2pj.dyndns.org> <440EF0B0.1010203@samsco.org> <20060308.090211.97454770.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:02 AM -0700 3/8/06, M. Warner Losh wrote: >In message: <440EF0B0.1010203@samsco.org> > Scott Long <scottl@samsco.org> writes: >: >: Yeah, diff increase with other FreeBSD branches is a big >: deal. While sharing between RELENG_4 and more recent >: branches is pretty hard these days, a lot can be shared >: between RELENG_5, RELENG_6, and HEAD. > >Would merging these to RELENG_6 help any? RELENG_5 is dead >after this release anyway... > >After all, with the new release cycle, there would never be >a good time to remove this old cruft from the tree since we'd >always have multiple branches to deal with. Let me play the advocate here for a few minutes... For what (little?) it is worth, I think this is a reasonable thing to do, particularly for the files were it reduces the diffs with other actively-developed projects such as NetBSD. I understand the issues of code churn, but I also remember the YEARS we spent debating whether we would move to ansi function definitions instead of K&R. We constantly agreed that such a move would be a good idea, but anytime anyone tried to do it, they got yelled at because "Today is not a good day to make that change". *IFF* these changes reduce diffs with NetBSD, then there is real value to that. Yes, we increase diffs with RELENG_4, but RELENG_4 is not being actively developed. We will not be comparing RELENG_4 to HEAD because someone just committed some great new feature to RELENG_4, but we will be doing that with the code in NetBSD. I'd also like to think that the other projects will be looking at our code to import some of our great new features into their code-base. The more they pick up, the better for both projects. And I assume that reducing diffs with them will make it easier for them to check over whatever we've been up to lately. I also appreciated the issue of code-churn making life harder for security branches. But if I'm not mistaken, we are already at the point that we do not necessarily fix security issues in RELENG_4. So, that leaves RELENG_5 and RELENG_6. If these changes are MFC'ed into RELENG_6, I think we will be in pretty good shape. Not that I'm volunteering to do any of it... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06230922c034c40373f2>