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