Date: Tue, 26 Feb 2002 14:01:49 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Warner Losh <imp@harmony.village.org> Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 exception.s genassym.c machdep.c mp_machdep.c mpapic.c swtch.s vm_machdep.c src/sys/i386/include cpufunc.h pcb.h src/sys/i386/isa apic_vector.s clock.c icu_vector.s intr_machdep.c intr_machdep.h npx.c src/sys/kern ... Message-ID: <Pine.BSF.4.21.0202261349400.98715-100000@beppo> In-Reply-To: <200202262143.g1QLh2L27678@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> How is it different than publishing patches on a web site? There are > a number of tools that one needs to have to get the patches, just like > in P4. The P4 repo is available from cvsup10, so you don't even need > to install P4 to see the patches. Because it encourages (and has encouraged) a side project with 'special' tools that subsets this overall project- by it's very nature precluding developers from openwly working together. I've had reservations for quite some time about this and mentioned this before. It came up again recently for me when David asked me to look at Sparc64 issues with the isp driver. Because the sparc64 effort is also using a separate p4 repository, the issue came up again and I asked 'why perforce?'. The net effect of all of the discussion (cordial though it was) was that I have very little interest in helping the overall sparc64 effort and will just fix the isp- when I get around to actually getting a FreeBSD/sparc64 netbooted. Jake's been quite helpful about info for this, but because the effort is a side group with p4, even if I run p4 (which I can do, btw), I was asked to not delta directly into the p4 depot. So, like many of the other 'sub projects' with FreeBSD, it violates (IMO) the democratic spirit of the project. Even if everyone means well. > > Our CVS meisters have told us in the past that branches on the CVS > tree are bad, and NetBSD's experience is that not more than one or two > are sustainable in the long run. This is not entirely true. A branch is good for doing major work that you intend to pull into the mainline at some point. It's hard on the people maintaining the branch because the major grunt work of pulling the head into the branch is a major file conflict PITA. There are many other tools that are, btw, quite adequate and better than CVS, that we could all use. Or we could all use p4- but the issue here isn't *really* the tool. The issue is that the tools are being used to subvert the spirit of the project. > I don't think P4 is the problem here. The problem is communication, > expectations and work habits. I think it's both. The establishment of side projects with different tools than we all use guarantees resentment and poor communication. Such methodologies are okay in a business where you have management actively involved- and perhaps having reasons for such a divided software development approach. In a volunteer project I don't believe it's helpful. However, like many things within FreeBSD over the last 6 months- I don't believe my views are really in accord with a number of other developers. This is, as I mentioned to somebody else, one of the 3 main reasons I no longer actively spend much time in FreeBSD. I don't expect you all to change your opinions about this- I've expressed mine- politely I hope. As I prefaced my mail to Julian/cc- to all of you- "FWIW". -amtt 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?Pine.BSF.4.21.0202261349400.98715-100000>