svn commit: r186730 - in head: lib/libusb20 sys/dev/usb2/controller sys/dev/usb2/core sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us...

[M. Warner Losh]

In message: <20090105205721.GH60686 at elvis.mu.org>
            Alfred Perlstein <alfred at FreeBSD.org> writes:
: * M. Warner Losh <imp at bsdimp.com> [090105 08:05] wrote:
: > In message: <20090105050415.GY60686 at elvis.mu.org>
: >             Alfred Perlstein <alfred at freebsd.org> writes:
: > : * M. Warner Losh <imp at bsdimp.com> [090104 09:11] wrote:
: > : > In message: <200901040012.n040C2gH040928 at svn.freebsd.org>
: > : >             Alfred Perlstein <alfred at FreeBSD.org> writes:
: > : > :   Sync with usb4bsd:
: > : > 
: > : > Alfred,
: > : > 
: > : > thanks for trudging these fixes into the tree.  It is a thankless job
: > : > that people will complain about...
: > : > 
: > : > Speaking of complaining, is there a review process that can be joined
: > : > for them that's more formal than "diff against hps' p4 tree and
: > : > complain?"
: > : 
: > : We're trying to figure out a way to do this.  We haven't had much
: > : luck exploring svk/hg/git as they're just about as much work as
: > : shipping patches back and forth.
: > : 
: > : I asked core for a restricted "users/hps" area under svn for Hans
: > : to put code, but that was denied, perhaps now it's time to reconsider
: > : that?
: > 
: > And also:
: > > In my part of the world we give credit or, at the very least, say "thank 
: > > you" to the sender, when we apply patches sent to us.
: > 
: > One of the things that works well in Linux is the patch queues that
: > they have.  You submit a patch, people talk about it, and various tags
: > get added to it.  They break things down into a series of mostly
: > independent patches.
: > 
: > Maybe we should try to initiate something like this so that we can
: > comment on changes more easily, as well as track submitters and the
: > like as things pass through Hans.
: > 
: > Consider it an experiment to see if we can do things to help improve
: > our world?
: 
: I guess so, but this can all be implemented via a sandbox in
: our VCS for Hans/me to use... or GNATS, but that just adds overhead.
: 
: I sort of feel this would be reinventing something that we already
: have.

We don't already have this.

The patch streams that are implemented elsewhere serve the purpose of
review and tracking.  Patches are posted to a mailing list, people
review them, they get committed upstream.  See, for example, the qemu
developer mailing list for one way this is done.  If we were to follow
that model, individual patches would be generated, posted there, and
then committed as patches if there were no objections.

While many of these features would be there in, say, an svn project
tree, the review before merge isn't.  Also, by forcing the patches to
be reviewed and committed individually, we retain more history than we
have now.

And we have fewer chances to undo changes that are committed between
big honkin' code drops into the tree.  We need to draw more developers
into this process.  It can't just be Hans feeding you patches
forever.  There has to be uptake by the greater FreeBSD community of
developers, or this usb stack will fail like the last one did.  We
need a bus-factor greater than 1.  It is my contention that having a
more public review process would help facilitate drawing more people
in...

Warner