svn commit: r211503 - head/sys/mips/atheros
M. Warner Losh
imp at bsdimp.com
Thu Aug 19 18:51:56 UTC 2010
In message: <4C6D6FD7.7060106 at freebsd.org>
Andre Oppermann <andre at freebsd.org> writes:
: On 19.08.2010 19:20, M. Warner Losh wrote:
: > In message:<4C6D2933.9020306 at freebsd.org>
: > Andre Oppermann<andre at freebsd.org> writes:
: > : On 19.08.2010 13:53, Adrian Chadd wrote:
: > :> Author: adrian
: > :> Date: Thu Aug 19 11:53:55 2010
: > :> New Revision: 211503
: > :> URL: http://svn.freebsd.org/changeset/base/211503
: > :>
: > :> Log:
: > :> Add some initial AR724X chipset support.
: > :>
: > :> This is untested but should at least allow an AR724X to boot.
: > :
: > : Isn't this something that should be done on a project branch and
: > : merged back when in a good working state?
: >
: > We don't have a branch for mips stuff these days. This stuff is OK,
: > since the AR724X is just being rolled out right now... For non AR724x
: > systems, this won't affect anything...
:
: I was more concerned about tree breakage for non-tested code. When
: developing something bleeding edge it is often useful to just commit
: some stuff and have it sorted out later. In head this is more
: dangerous. A small AR724X development branch would be ideal for
: this. Branching is cheap with SVN these days.
Merging isn't that cheap with svn. The svn:mergeinfo properties make
them a pita. Given that this code won't break anything, except
possibly the now-unsupported AR724x, I think a branch would be
overkill. We'd have to drag that branch along all the time until we
can get actual hardware to test it on, which is a high overhead.
Warner
More information about the svn-src-all
mailing list