Felipe Balbi wrote: > From now on, please help us do a better job and only send _fixes_ during > the -rc cycle. I'll be accepting new code by -rc6 only. If you send new > code before that, I'll comment on the patch and delete it from my inbox. > Why can't we follow Greg's model and keep two queues - one with fixes for the current cycle, and one with features for the merge window? That way, we give people the ability to test the new features too. Also, if it's okay with you and Greg, I would prefer that there were only one USB queue - Greg can take the patches and add it to his series. That way, we don't need to track multiple trees. It shouldn't be much work now, as most of the MUSB code is in - so we can treat MUSB the same way the rest of the USB code is treated. > Also, let's try to setup a few goals we want to achieve on each major > release. There's plenty of goofy code we still have to cleanup, I have > to prepare the mode1 patches again, it would be nice to decouple the > arch code (blackin.c omap2430.c tusb010.c) from the core musb code so > that we could compile everything in and better test the compilation > environment. > > I'll setup a page at http://elinux.org/MUSB so we can add goals there. > Also information about supported hardware etc. If you have spare time, > please help improving the page. Sounds good. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
