Peter Chen <peter.chen@xxxxxxxxxxxxx> writes: > On Tue, Feb 26, 2013 at 02:47:34PM +0100, Marc Kleine-Budde wrote: >> On 02/26/2013 02:25 PM, Alexander Shishkin wrote: >> > Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> writes: >> > >> >> On 02/26/2013 11:56 AM, Alexander Shishkin wrote: >> >>> Peter Chen <peter.chen@xxxxxxxxxxxxx> writes: >> >>> >> >>>> Hi Alex, >> >>> >> >>> Hi, >> >>> >> >>>> Do we have a chipidea repo which is queued for mainline? >> >>>> We have several patchsets for chipidea these monthes, I >> >>>> don't know their status. For me, I would like based >> >>>> on your tree if it exists. >> >>> >> >>> I thought about it, but then it seems like having a separate branch is >> >>> bound to be confusing to most people. I'd much rather prefer everything >> >>> go to usb-next, and this is my current plan. Since Greg will start >> >>> applying new stuff to usb-next after -rc1 is tagged, I'll send my >> >>> current stash of patches for inclusion then. If your patchset, for >> >> >> >> Can we have a look at your queued patches? >> > >> > Sure, >> > http://marc.info/?l=linux-usb&m=135902434508839 >> > >> >>> example, has conflicts with my stuff that's not merged, I'll try to take >> >>> care of resolving the conflicts and submit everything to Greg. In other >> >>> words, it should be always ok to base your chipidea patchsets on >> >>> usb-next. >> >>> >> >>> Let me know if this sounds reasonable to you. >> >> >> >> Michael has already done that work (some S-o-b form Michael are missing) >> >> and rebased Sascha's and Peter's patches to current linus/master, see >> >> this tree : >> >> >> >> http://git.pengutronix.de/?p=mgr/linux.git;a=shortlog;h=refs/heads/chipidea-for-v3.10 >> > >> > Taking a quick look, quite some of those patches are not ready for >> > inclusion yet. So if the question is, do we need a -next tree for all >> > the chipidea patchsets floating around, it might be a good thing. But >> > it's not what Peter was asking in the first place. >> >> I suggest that we have a branch that holds all chipidea patches that are >> ready for mainline. Otherwise it's really hard to code any new features > > I agree. > > Alex, you can have a repo at github or any other places which is based > on usb-next, and add it to MAINTAINERS. We can develop the new feature > based on your repo. Greg can pull it directly if he agrees or you can send > your queued patchset before every merge windows. Ok, let's try this. I have a linux-ci repo on github, might as well do something useful with it [1], [2]. Currently, the branch called "ci-for-greg" is where I stack patches that I'm planning to be sending (via email) to Greg when the time is right. The "policy" is such that it'll be rebased on top of Greg's usb-next and probably often, so no fast forwards. Also patches may be dropped from it if necessary. Since the branch is not for pulling, the "no rebase" rule doesn't apply. If you have comments/suggestions/etc for a patch that is in this branch, please reply to the email with that patch on the mailing list and not via github infrastructure. Sounds reasonable? I'm now scouting my inbox for more candidates for this branch. Please don't re-send the patches that have already been sent, unless you have new versions of those, I have them all. Do send new versions, though. [1] git://github.com/virtuoso/linux-ci.git ci-for-greg [2] https://github.com/virtuoso/linux-ci/commits/ci-for-greg Regards, -- Alex -- 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
